【Java设计模式系列】创建型 - 单例模式

单例模式（Singleton Pattern）属于创建类型的一种常用的软件设计模式。

单例对象保证全局（或指定上下文中，如进程，线程内唯一）仅有一个实例存在，并提供一个该唯一实例的访问点。

为什么需要单例模式

打井喝水，并不是每个人想喝水就要打一口井。

• 优点：在内存里只有一个实例，所以能够节约系统资源，减少了内存的开销，尤其是频繁的创建和销毁实例，可以提高系统效率，同时也能够严格控制客户对它的访问。

• 缺点：也正是因为系统中只有一个实例，这样就导致了单例类的职责过重，违背了“单一职责原则”，同时也没有抽象类，这样扩展起来有一定的困难。

优点即缺点，所以更应该说是特点，在特定场景下使用。

• 常见应用场景

  1. spring bean
  2. 数据库连接
  3. 需要频繁的进行创建和销毁的对象
  4. 创建对象时耗时过多或耗费资源过多(重量级对象)
  5. 经常用到的对象、工具类对象、频繁访问数据库或文件的对象(数据源、session工厂)

结构

实现方式

要实现单例模式，关键有 3 个要素：

1. 单例类只有一个实例对象；如instance；此为单例模式的核心要素。
2. 该单例对象必须由单例类自行创建；一般情况下会将构造函数声明为私有的，如private Singleton()；这样外部无法实例化，也无法被继承，此举为保证唯一性，从而避免勿用。
3. 单例类对外提供一个访问该单例的全局访问点；如getInstance()；由于已阻止外部构建，即单例类是一个只读类，外部不能创建或修改，需提供一个读取接口。

即为了避免城市被私人挖得千疮百孔，没收公众的挖井工具，收归专门管理，但开放水利给公众使用。

具体常用的几种实现方法：

1. 饿汉式

饿汉式顾名思义就是把食物（对象）提前做好，需要时直接拿取即可使用（吃掉）。简而言之即预先构建。

// 饿汉式单例
public class Eager {

    // 提前把对象实例化，此对象实例全局唯一
    private final static Eager instance = new Eager();

    // 私有化构造器，不允许外部使用，以免破坏唯一性
    private Eager() {
        System.out.println("singleton have been created");
    }

    // 提供唯一访问点
    public static Eager getInstance() {
        return instance;
    }

    // 功能特性
    public String eatSomething(String something) {
        return something + " eat";
    }
}

// 测试代码
@Test
public void testEager() {
    // TODO: make it multithread
    assertEquals("cake eat", Eager.getInstance().eatSomething("cake"));
}

饿汉式是最省心的一种方案，其缺点就是占用资源，因为实例是提前创建的而不是按需，因此就算对象不被使用也会一直占据内存空间，其在启动时就需要耗时进行构建。

当然在正常工程使用时，基本上单例类都是需要实例化的。因此在工程上这是常用的一种方案。

2. 懒汉式（双检锁方案）

考虑到饿汉式占据资源的缺点，而资源有时非常宝贵，如同缓存等。因此有了懒汉式的构建方案，即只在需要用到单例对象时才构建，简而言之即按需构建。

因此根据特性，即最开始不对instance赋值，只在getInstance方法被调用时再进行初始化。这是最容易想到的，但有并发问题，因为这种方法在运行时更改了全局共享资源instance。

// 懒汉式单例 单线程版（有并发问题）
public class Lazier {

    private static Lazier instance = null;

    private Lazier() {
        System.out.println("singleton have been created");
    }

    public static Lazier getInstance() {
        if (instance == null) {
            instance = new Lazier();
        }
        return instance;
    }

    public String work() {
        return "disagree";
    }
}

如上简单实现，在多线程场景下，如有线程A运行到第 8 行判断到instance == null，通过了判断，然后线程卡住，另一个线程B也运行到第 8 行判断到instance == null，此时也会通过判断，因为线程A卡住未对其进行初始化，因此线程B会运行第 9 行构建instance并返回，而线程A恢复后也会继续往下执行到第 9 行，此时便出现了两次new Lazier()的调用，单例对象出现构建多次的问题，浪费资源严重甚至会引起系统异常。

为解决上述问题，一个简单的想法就是加锁，让多个线程在并发问题发生点（更新共享资源处）保持串行，即可保证同一时刻只有一个线程进入。

// 懒汉式单例 普通加锁版
public class Lazier {

    // 加 volatile 关键字禁止指令重排，同时保证 instance 修改后其他线程可以立即得知。
    private static volatile Lazier instance = null;

    private Lazier() {
        System.out.println("singleton have been created");
    }

    public static Lazier getInstance() {
        // 加锁，当然把 synchronized 加到方法上也是一种方式。
        synchronized (Lazier.class) {
            if (instance == null) {
                instance = new Lazier();
            }
        }
        return instance;
    }

    public String work() {
        return "disagree";
    }
}

这种加锁方式可以解决并发问题，但是所有的线程任何时刻都需要排队，且同一时刻只能有一个线程进入，所以典型的加锁代价是降低了吞吐量，严重影响性能。

回到最初的解决并发问题时的并发问题点上，观察到最初需要解决的并发问题并不是任何时刻都会出现，是在instance == null的时候会出现，而本次加锁则是大范围锁，导致无论何时一个线程进来就需要取锁排队变成串行方式。因此可以通过降低锁的范围来对加锁场景剪枝，即只针对确切并发问题场景加锁。

// 懒汉式单例 单检加锁版（有并发问题）
public class Lazier {

    private static volatile Lazier instance = null;

    private Lazier() {
        System.out.println("singleton have been created");
    }

    @Deprecated
    public static Lazier getInstance() {
        if (instance == null) {
            // 降低锁的范围
            synchronized (Lazier.class) {
                instance = new Lazier();
            }
        }
        return instance;
    }

    public String work() {
        return "disagree";
    }
}

以上降低了锁的范围，相当于最开始的全部加锁，变成只对if (instance == null)成立时加锁，放开else情况，实现剪枝。但是目前的实现方式是不完全的，因为仍然有并发问题。即同最开始一样，可能有多个线程通过了instance == null的判断，此时就算排队，也避免不了其执行后续初始化代码。

所以解决办法是在线程获取锁继续往下执行后再做一次instance == null判断，来决定是否跳过初始化代码，保证只有一次初始化。而这种方式也就是所谓的 Double Check Lock(DCL)，即双重检查加锁。

// 懒汉式单例 双检加锁版
public class Lazier {

    private static volatile Lazier instance = null;

    private Lazier() {
        System.out.println("singleton have been created");
    }

    @Deprecated
    public static Lazier getInstance() {
        // 第一次检查
        if (instance == null) {
            // 降低锁的范围
            synchronized (Lazier.class) {
                // 第二次检查
                if (instance == null) {
                    instance = new Lazier();
                }
            }
        }
        return instance;
    }

    public String work() {
        return "disagree";
    }
}

其实更直观的说，是剪枝，把不需要加锁的场景（即instance已经赋值了的场景）作为卫语句，直接返回。

// 懒汉式单例 剪枝写法
public class Lazier {

    private static volatile Lazier instance = null;

    private Lazier() {
        System.out.println("singleton have been created");
    }

    @Deprecated
    public static Lazier getInstance() {
        // 把无并发问题的场景剪枝掉。
        if (instance != null) {
            return instance;
        }
        // 有并发问题的场景加锁
        synchronized (Lazier.class) {
            if (instance == null) {
                instance = new Lazier();
            }
        }
        return instance;
    }

    public String work() {
        return "disagree";
    }
}

懒汉模式解决了内存占用问题，但同时也降低了并发吞吐能力，同时从实现的方式上看，比饿汉模式复杂（看篇幅都知道为什么说饿汉式是最省心的了）。因此在实际工程使用时需视情况选择。

3. 静态内部类（懒汉的另一种实现方式）

为解决懒汉模式比较复杂的写法，还有一种采用内部类的方式利用 JVM 的 ClassLoader 自身的机制来保证线程安全。
属于一种写法很饿汉，效果却很懒汉的方式。具体写法如下：

// 懒汉式单例 内部类方式
public class InnerSingleton {

    private InnerSingleton() {
        System.out.println("singleton have been created");
    }

    public static InnerSingleton getInstance() {
        return InnerSingletonFactory.instance;
    }

    public String doSomething(String something) {
        return something + " happened";
    }

    private static class InnerSingletonFactory {
        // 当内部类第一次访问时，创建对象实例，所以仍是懒加载
        protected static final InnerSingleton instance = new InnerSingleton();
    }
}

根据 JVM 的机制，当外部类被访问时，并不会加载内部类，所以只要不访问 InnerSingletonHolder 这个内部类，instance 就不会初始化，不占据资源，因而实现懒汉懒加载的效果，同时 JVM 的类加载机制保证了线程安全，这样既解决了资源浪费的问题，也避免了并发问题。本质上属于懒汉式的一种解决方案。

4. 枚举（懒汉的另一种实现方式）

类似内部类的实现，也可以枚举来实现单例，同样是靠 JVM 的机制解决资源与并发的问题。本质上也属于懒汉式的一种解决方案。具体实现方式如下：

// 懒汉式单例 枚举方式
public enum EnumSingleton {

    INSTANCE;

    private EnumSingleton() {
        System.out.println("singleton have been created");
    }

    public String doSomething(String something) {
        return something + " happened";
    }
}

5. ThreadLocal（已失去单例意义）

最后还有一种纯搞笑而流于表面的实现方式，就是通过 ThreadLocal 来解决并发问题。但实际上并没有起到资源节省的目的，此种单例模式已经失去实际意义。

使用案例

// 待补充实际工作上项目的使用案例。

引申

本模式的主要设计思想在于控制某个类只能有指定数量的实例，对于单例模式，特定的该数量为1，所以关键设计思想不在于是否是一个实例，而在于保证实例数量有限有边界，且要对实例进行重用以避免频繁的构建销毁。同样的，某些场景下则需要有限的多例，例如连接池等。为达到重用实例的目的，需要避免其频繁构建销毁，但因为此类实例在使用时是有状态的，即处于使用状态时需要排他独占，这样单例就无法满足吞吐量，由此可以类似单例思想控制只能生成指定数量的连接实例，轮询使用，即能满足重用，又避免在大并发时生成无限多例导致的内存泄露。

总结

一般项目里，建议使用饿汉方式，因为基本上会制作为单例的类都是需要随时使用的，所以节省到这部分资源的概率较低，而且尽可能在启动时即初始化好全部实例，而不建议按需时通过并发加锁的方式，影响系统吞吐能力，代价较大。

只有在要明确需要实现延迟加载效果时，才使用懒汉式。懒汉式建议采用内部类实现方式，简洁同时线程安全，如果涉及到反序列化等需求时，可以尝试使用枚举方式，该方式实际上较少项目使用过，笔者接触过的项目还没有使用过这种枚举方式的。如果有其他特殊的需求，可以考虑使用双重校验锁方式。

优先级推荐：饿汉 > 懒汉内部类 > 懒汉枚举(按需) > 懒汉双检锁。