钻钻 “单例” 的牛角尖-阿里云开发者社区

首先什么是单例？就一条基本原则，单例对象的类只会被初始化一次。在 Java 中，我们可以说在 JVM 中只存在该类的唯一一个对象实例。在 Android 中，我们可以说在程序运行期间，该类有且仅有一个对象实例。说到单例模式的实现，你们肯定信手拈来，什么懒汉，饿汉，DCL，静态内部类，门清。在说单例之前，考虑下面几个问题：

你的单例线程安全吗?
你的单例反射安全吗？
你的单例序列化安全吗？

今天，我就来钻钻牛角尖，看看你们的单例是否真的 “单例”。

单例的一般实现

饿汉式

public class HungrySingleton {
    private static final HungrySingleton mInstance = new HungrySingleton();
    private HungrySingleton() {
    }
    public static HungrySingleton getInstance() {
        return mInstance;
    }
}
复制代码

私有构造器是单例的一般套路，保证不能在外部新建对象。饿汉式在类加载时期就已经初始化实例，由于类加载过程是线程安全的，所以饿汉式默认也是线程安全的。它的缺点也很明显，我真正需要单例对象的时机是我调用 getInstance() 的时候，而不是类加载时期。如果单例对象是很耗资源的，如数据库，socket 等等，无疑是不合适的。于是就有了懒汉式。

懒汉式

public class LazySingleton {
    private static LazySingleton mInstance;
    private LazySingleton() {
    }
    public static synchronized LazySingleton getInstance() {
        if (mInstance == null)
            mInstance = new LazySingleton();
        return mInstance;
    }
}
复制代码

实例化的时机挪到了 getInstance() 方法中，做到了 lazy init ，但也失去了类加载时期初始化的线程安全保障。因此使用了 synchronized 关键字来保障线程安全。但这显然是一个无差别攻击，管你要不要同步，管你是不是多线程，一律给我加锁。这也带来了额外的性能消耗。这点问题肯定难不倒程序员们，于是，双重检查锁定(DCL, Double Check Lock) 应运而生。

DCL

public class DCLSingleton {
    private static DCLSingleton mInstance;
    private DCLSingleton() {
    }
    public static DCLSingleton getInstance() {
        if (mInstance == null) {                    // 1
            synchronized (DCLSingleton.class) {     // 2
                if (mInstance == null)              // 3
                    mInstance = new DCLSingleton(); // 4
            }
        }
        return mInstance;
    }
}
复制代码

1 处做第一次判断，如果已经实例化了，直接返回对象，避免无用的同步消耗。2 处仅对实例化过程做同步操作，保证单例。3 处做第二次判断，只有 mInstance 为空时再初始化。看起来时多么的完美，保证线程安全的同时又兼顾性能。但是 DCL 存在一个致命缺陷，就是重排序导致的多线程访问可能获得一个未初始化的对象。

首先记住上面标记的 4 行代码。其中第 4 行代码 mInstance = new DCLSingleton(); 在 JVM 看来有这么几步：

为对象分配内存空间

初始化对象

将 mInstance 引用指向第 1 步中分配的内存地址

在单线程内，在不影响执行结果的前提下，可能存在指令重排序。例如下列代码：

int a = 1;
int b = 2;
复制代码

在 JVM 中你是无法确保这两行代码谁先执行的，因为谁先执行都不影响程序运行结果。同理，创建实例对象的三部中，第 2 步 初始化对象 和第 3 步 将 mInstance 引用指向对象的内存地址 之间也是可能存在重排序的。

为对象分配内存空间

将 mInstance 引用指向第 1 步中分配的内存地址

初始化对象

这样的话，就存在这样一种可能。线程 A 按上面重排序之后的指令执行，当执行到第 2 行 将 mInstance 引用指向对象的内存地址 时，线程 B 开始执行了，此时线程 A 已为 mInstance 赋值，线程 B 进行 DCL 的第一次判断 if (mInstance == null) ,结果为 false，直接返回 mInstance 指向的对象，但是由于重排序的缘故，对象其实尚未初始化，这样就出问题了。还挺绕口的，借用《Java 并发编程艺术》中的一张表格，会对执行流程更加清晰。

时间	线程 A	线程 B
t1	A1: 分配对象的内存空间
t2	A3: 设置 mInstance 指向内存空间
t3		B1: 判断 mInstance 是否为空
t4		B2: 由于 mInstance 不为空，线程 B 将访问 mInstance 指向的对象
t5	A2: 初始化对象
t6	A3: 访问 mInstance 引用的对象

A3 和 A2 发生重排序导致线程 B 获取了一个尚未初始化的对象。

说了半天，该怎么改？其实很简单，禁止多线程下的重排序就可以了，只需要用 volatile 关键字修饰 mInstance 。在 JDK 1.5 中，增强了 volatile 的内存语义，对一个volatile 域的写，happens-before 于任意后续对这个 volatile 域的读。volatile 会禁止一些处理器重排序，此时 DCL 就做到了真正的线程安全。

静态内部类模式

public class StaticInnerSingleton {
    private StaticInnerSingleton(){}
    private static class SingletonHolder{
        private static final StaticInnerSingleton mInstance=new StaticInnerSingleton();
    }
    public static StaticInnerSingleton getInstance(){
        return SingletonHolder.mInstance;
    }
}
复制代码

鉴于 DCL 繁琐的代码，程序员又发明了静态内部类模式，它和饿汉式一样基于类加载时器的线程安全，但是又做到了延迟加载。SingletonHolder 是一个静态内部类，当外部类被加载的时候并不会初始化。当调用 getInstance() 方法时，才会被加载。

枚举单例暂且不提，放在最后再说。先对上面的单例模式做个检测。

真的是单例？

还记得开头的提问吗？

你的单例线程安全吗?
你的单例反射安全吗？
你的单例序列化安全吗？

上面大篇幅的论述都在说明线程安全。下面看看反射安全和序列化安全。

反射安全

直接上代码，我用 DCL 来做测试：

public static void main(String[] args) {
    DCLSingleton singleton1 = DCLSingleton.getInstance();
    DCLSingleton singleton2 = null;
    try {
        Class<DCLSingleton> clazz = DCLSingleton.class;
        Constructor<DCLSingleton> constructor = clazz.getDeclaredConstructor();
        constructor.setAccessible(true);
        singleton2 = constructor.newInstance();
    } catch (Exception e) {
        e.printStackTrace();
    }
    System.out.println(singleton1.hashCode());
    System.out.println(singleton2.hashCode());
}
复制代码

执行结果：

1627674070
1360875712
复制代码

很无情，通过反射破坏了单例。如何保证反射安全呢？只能以暴制暴，当已经存在实例的时候再去调用构造函数直接抛出异常，对构造函数做如下修改：

private DCLSingleton() {
    if (mInstance!=null)
        throw new RuntimeException("想反射我，没门！");
}
复制代码

上面的测试代码会直接抛出异常。

序列化安全

将你的单例类实现 Serializable 持久化保存起来，日后再恢复出来，他还是单例吗？

public static void main(String[] args) {
    DCLSingleton singleton1 = DCLSingleton.getInstance();
    DCLSingleton singleton2 = null;
    try {
        ObjectOutput output=new ObjectOutputStream(new FileOutputStream("singleton.ser"));
        output.writeObject(singleton1);
        output.close();
        ObjectInput input=new ObjectInputStream(new FileInputStream("singleton.ser"));
        singleton2= (DCLSingleton) input.readObject();
    } catch (Exception e) {
        e.printStackTrace();
    }
    System.out.println(singleton1.hashCode());
    System.out.println(singleton2.hashCode());
}
复制代码

执行结果：

644117698
793589513
复制代码

不堪一击。反序列化时生成了新的实例对象。要修复也很简单，只需要修改反序列化的逻辑就可以了，即重写 readResolve() 方法，使其返回统一实例。

protected Object readResolve() {
    return getInstance();
}
复制代码

脆弱不堪的单例模式经过重重考验，进化成了完全体，延迟加载，线程安全，反射安全，序列化安全。全部代码如下：

public class DCLSingleton implements Serializable {
    private static DCLSingleton mInstance;
    private DCLSingleton() {
        if (mInstance!=null)
            throw new RuntimeException("想反射我，没门！");
    }
    public static DCLSingleton getInstance() {
        if (mInstance == null) {
            synchronized (DCLSingleton.class) {
                if (mInstance == null)
                    mInstance = new DCLSingleton();
            }
        }
        return mInstance;
    }
    protected Object readResolve() {
        return getInstance();
    }
}
复制代码

枚举单例

枚举看到 DCL 就开始嘲笑他了，“你瞅瞅你那是啥，写个单例费那大劲呢？” 于是撸起袖子自己写了一个枚举单例：

public enum EnumSingleton {
    INSTANCE;
}
复制代码

DCL 反问，“你这啥玩意，你这就是单例了？我来扒了你的皮看看！” 于是 DCL 掏出 jad ，扒了 Enum 的衣服，拉出来示众：

public final class EnumSingleton extends Enum {
    public static EnumSingleton[] values() {
        return (EnumSingleton[])$VALUES.clone();
    }
    public static EnumSingleton valueOf(String s) {
        return (EnumSingleton)Enum.valueOf(test/singleton/EnumSingleton, s);
    }
    private EnumSingleton(String s, int i) {
        super(s, i);
    }
    public static final EnumSingleton INSTANCE;
    private static final EnumSingleton $VALUES[];
    static {
        INSTANCE = new EnumSingleton("INSTANCE", 0);
        $VALUES = (new EnumSingleton[] {
            INSTANCE
        });
    }
}
复制代码

我们依次来检查枚举单例的线程安全，反射安全，序列化安全。

首先枚举单例无疑是线程安全的，类似饿汉式，INSTANCE 的初始化放在了 static 静态代码段中，在类加载阶段执行。由此可见，枚举单例并不是延时加载的。

对于反射安全，又要掏出上面的检测代码了，根据 EnumSingleton 的构造器，需要稍微做些改动：

public static void main(String[] args) {
    EnumSingleton singleton1 = EnumSingleton.INSTANCE;
    EnumSingleton singleton2 = null;
    try {
        Class<EnumSingleton> clazz = EnumSingleton.class;
        Constructor<EnumSingleton> constructor = clazz.getDeclaredConstructor(String.class,int.class);
        constructor.setAccessible(true);
        singleton2 = constructor.newInstance("test",1);
    } catch (Exception e) {
        e.printStackTrace();
    }
    System.out.println(singleton1.hashCode());
    System.out.println(singleton2.hashCode());
}
复制代码

结果直接报错，错误日志如下：

java.lang.IllegalArgumentException: Cannot reflectively create enum objects
  at java.lang.reflect.Constructor.newInstance(Constructor.java:417)
  at singleton.SingleTest.main(SingleTest.java:16)
复制代码

错误发生在 Constructor.newInstance() 方法，又要从源码中找答案了，在 newInstance() 源码中，有这么一句：

if ((clazz.getModifiers() & Modifier.ENUM) != 0)
            throw new IllegalArgumentException("Cannot reflectively create enum objects");
复制代码

如果是枚举修饰的，直接抛出异常。和之前的对抗反射的手段一致，压根就不给你反射。所以，枚举单例也是天生反射安全的。

最后枚举单例也是序列化安全的，上篇文章中已经说明过，你可以运行测试代码试试。

看起来枚举单例的确是个不错的选择，代码简单，又能保证绝大多数情况下的单例实例唯一。但是真正在开发中大家好像用的并不多，更多的可能应该是枚举在 Java 1.5 中才添加，大家默认已经习惯了其他的单例实现方式。

代码最少的单例？

说到枚举单例代码简单，Kotlin 第一个站出来不服了。我敢说第一，谁敢说第二，给你们献丑了：

object KotlinSingleton { }
复制代码

jad 反编译一下：

public final class KotlinSingleton {
    private KotlinSingleton(){
    }
    public static final KotlinSingleton INSTANCE;
    static {
        KotlinSingleton kotlinsingleton = new KotlinSingleton();
        INSTANCE = kotlinsingleton;
    }
}
复制代码

可以看到，Kotlin 的单例其实也是饿汉式的一种，不钻牛角尖的话，基本可以满足大部分需求。

吹毛求疵的谈了谈单例模式，可以看见要完全的保证单例还是有很多坑点的。在开发中并没有必要钻牛角尖，例如 Kotlin 默认提供的单例实现就是饿汉式而已，其实已经可以满足绝大多数的情况了。

钻钻 “单例” 的牛角尖

单例的一般实现

饿汉式

懒汉式

DCL

静态内部类模式

真的是单例？

反射安全

序列化安全

枚举单例

代码最少的单例？

热门文章

最新文章

相关电子书

热门

活动广场

任务中心

开发者评测

高校计划

乘风者计划

训练营

阿里云MVP

话题

直播

下载

镜像站

技术资料

插件

钻钻 “单例” 的牛角尖

单例的一般实现

饿汉式

懒汉式

DCL

静态内部类模式

真的是单例？

反射安全

序列化安全

枚举单例

代码最少的单例？

热门文章

最新文章

相关电子书