死磕设计模式-单例

单例模式，可能是唯一一个我们谈到时，每个工程师都会二眼放光，滔滔不绝的模式，除了它最简单直接外，还因为我们“自以为”对它了如指掌，这篇文章带大家做个总结，死磕单例模式的方方面面。

单例的需求由来

大概有以下二种场景需要单例

有些对象只应该存在一个，比如 “上帝” “女娲”等等，天然具有单一的性质
我们造出来的配置类，管理类，比如UserManager，ServiceManager等等，只需维护一处，可以全局引用

单例的四种实现

实现一个单例，我们要考虑以下几点。

如何防止外部调用new关键字来创建新的对象
如何做到防止通过对象序列化来创建新的对象
实现了cloneable的类，如何防止clone来创建新的对象
如何防止反射调用构造器来创建新的对象
如何做到线程安全

总结一句话，如何线程安全的创建唯一实例对象。先看一下Java中如何具体实现单例。

单例实现-懒汉模式

public class UserManager {
    private static UserManager instance = new UserManager();
    private UserManager() { }
    public static UserManager getInstance() {
        return instance;
    }
}

首先通过私有化构造器，禁止了外部new的可能性，然后instance是static修饰的，所以在类被首次加载后，调用init 的时候，instance会被初始化，JVM保证类加载过程的线程安全，所以instance也是线程安全的。因为在类加载初始化的时候，单例就被创建出来了，所以相对于按需延时加载，这种写法如果有大量单例需要创建，在系统刚启动时内存压力比较大。同时上面的写法也没有能够禁止序列化和反射对单例的破坏（关于这个我们放到最后来解决）。

单例实现-Double Check

    private static volatile UserManager instance;

    private UserManager() {}

    public static UserManager getInstance() {
        if (instance == null) {
            synchronized (UserManager.class) {
                if (instance == null) {
                    instance = new UserManager();
                }
            }
        }
        return instance;
    }

这也是很经典的单例实现，通过二次判空检查，而且只有在第一次初始化时getInstance会加锁，后面的获取都不会加锁，时间和空间效率都很高。这里要注意的一点是instance一定要加volatile修饰符。关于这一点，很多同学可能会理解的不够全面，下面我来详细分析一下。首先因为在创建UserManager的时候，我们是有加锁的，而且锁的对象是UserManager这个Class对象。比如线程A获得了锁，开始new UserManager()，并且赋值给了instance，这时候线程B开始调用getInstance()来获取单例对象，由于锁拥有可见性，所以线程A的赋值happen-before线程B的获取，表面上看一切很完美，但是在jdk1.5之前，volatile语意还没有被加强，不能禁止指令重排序。

instance = new UserManager();

这条语句，其实可以被看做三条伪代码。

alloc userManager （堆上分配内存）
userManager init （对象初始化）
instance = userManager 注意，alloc必须首先执行，但是init 和第三条赋值语句，JVM并没有做定义，也就是说如果不加volatile，它们可以被重排序。一旦被重排序，线程B在获取instance时，有可能获取到的instance还没有执行init，这就是一次很危险的调用。但是加上volatile关键字，在jdk1.5之后，就不会再有这个问题了。

单例实现-静态内部类

    private UserManager() {}
    
    private static UserManager getInstance() {
        return SingltonHolder.sInstance;
    }

    private static class SingltonHolder {
        private static UserManager sInstance = new UserManager();
    }

静态内部类的方式实现的单例同样是线程安全的，由JDK来保证。同时也具有延时加载的特性。这种写法对比Double-Check更简洁，推荐使用。

单例实现-枚举

Effective Java中推荐使用枚举的方式来实现单例，我们来看一下

public enum UserManager {
    INSTANCE;
}

很简洁，但我们知道，枚举是Java提供的语法糖，我们解语法糖看下它的具体代码

public final class com.dig.deep.design.singlton.UserManager extends java.lang.Enum<com.dig.deep.design.singlton.UserManager> {
  public static final com.dig.deep.design.singlton.UserManager INSTANCE;
  private static final com.dig.deep.design.singlton.UserManager[] $VALUES;
  public static com.dig.deep.design.singlton.UserManager[] values();
  public static com.dig.deep.design.singlton.UserManager valueOf(java.lang.String);
  private com.dig.deep.design.singlton.UserManager();
  static {};
}

可以看到解语法糖后的UserManager，构造器也是私有的，有个一个static final 的INSTANCE类常量，可以大胆猜测，JVM在加载枚举类时，会给所有的枚举项赋值，同时会保证过程的线程安全。

如何防止单例被破坏

我们上面有提到过，一个完整的单例需要做到防止

对象序列化对单例语意的破坏
反射对单例语意的破坏
clone对单例语意的破坏

解决对象序列化的问题

        try {
            UserManager userManager = UserManager.instance;
            FileOutputStream fileOutputStream = new FileOutputStream("user");
            ObjectOutputStream objectOutputStream = new ObjectOutputStream(fileOutputStream);
            objectOutputStream.writeObject(userManager);

            FileInputStream fileInputStream = new FileInputStream("user");
            ObjectInputStream objectInputStream = new ObjectInputStream(fileInputStream);
            UserManager newUserManager = (UserManager) objectInputStream.readObject();

            System.out.println("is equal: " + (userManager == newUserManager));
        } catch (IOException e) {
            e.printStackTrace();
        }

输出是false，经过序列化和反序列化后，生成了二个单例对象，显然破坏了单例的语意，解决这个问题，我们可以给UserManager增加一个readResolve方法, 并在其中返回单例对象。

    private Object readResolve() {
        return instance;
    }

解决反射的问题

        Class clazz = UserManager.class;
        Constructor[] constructors = clazz.getDeclaredConstructors();
        try {
            constructors[0].setAccessible(true);
            UserManager newUserManager = (UserManager) constructors[0].newInstance();
        } catch (Exception e) {
            e.printStackTrace();
        }

如果开发者真的使用反射来作恶，谁能拦得住呢?虽然反射最终调用的还是我们的私有构造器，在构造器里面我们可以加一些判断逻辑，但是还是不能涵盖所有的情况，因为毕竟我们的单例实现多种多样，有延时加载的，有非延时加载的。但是通过Enum方式实现的单例是不能够被反射的，如果尝试反射Enum的构造器，会抛出一个异常，所以Enum方式实现的单例对反射安全。

解决clone的问题

尽量不要给单例实现cloneable接口，如果非要实现，也在重写的clone方法里，返回此单例对象。

    @Override
    protected Object clone() throws CloneNotSupportedException {
        return getInstance();
    }

总结

单例模式比较简单，同时我们日常工作也用的很频繁，工程师有必要对它有个全面了解，在选择实现方案时做到心中有数。