Java

单例的线程安全及序列化问题

饿汉方式单例到底有多“饿”？
静态内部类为什么是延迟加载的？
枚举方式单例是延迟加载的吗？
饿汉、静态内部类、枚举方式单例为什么是线程安全的？
序列化为什么会破坏单例模式？
怎么防止序列化破坏单例模式？
枚举方式单例是怎么避免序列化破坏的？

单例模式可以说是最简单的设计模式了，但在使用时也有一些问题需要注意，比如线程安全性和序列化破坏。本文以几个问题为出发点，分析延迟加载、线程安全以及序列化三个方面，深入了解一下单例模式的各种姿势，以便在今后使用时追求极致性能 ⊙﹏⊙‖∣°

延迟加载

饿汉方式

先来看一下饿汉方式实现的单例：

1
2
3
4
5
6
7
8
9
10
public class Singleton {

    private static Singleton instance = new Singleton();

    private Singleton() { }

    public static Singleton getInstance() {
        return instance;
    }
}

与饿汉方式一并提起的往往还有懒汉方式，对比而言，懒汉方式具有延迟加载（这里的加载指创建 Singleton 实例）的优点。这容易让人对饿汉方式有一个恶劣的刻板印象：它的性能很不好！没有使用它的时候它就会初始化，白白占用资源！

现在我们来思考一下，饿汉方式单例到底有多“饿”？它到底什么时候会初始化呢？我们知道类加载的时候会初始化静态资源，所以饿汉方式的初始化时机就是类加载时机，回顾一下类加载的时机：

  • 使用new关键字实例化对象
  • 调用一个类的静态方法
  • 读取一个类的静态字段（被 final 修饰已在编译期把结果放在常量池的静态字段除外）

当使用单例时，往往都是先调用 getInstance() 获取单例，几乎不会涉及其他的静态方法或字段，所以大多数情况下，饿汉方式同懒汉方式一样是延迟加载的！如果你的单例只暴露了 getInstance() 方法（个人感觉也是比较规范的写法），那就放心的使用饿汉方式吧！如果别人 diss 了你的饿汉方式，那就 diss 回去让他去复习类加载机制 >_<|||

静态内部类

静态内部类方式单例实现如下：

1
2
3
4
5
6
7
8
9
10
11
12
public class Singleton {

    private static class SingletonHolder {
        private static final Singleton INSTANCE = new Singleton();
    }

    private Singleton() {}

    public static Singleton getInstance() {
        return SingletonHolder.INSTANCE;
    }
}

相比饿汉方式，这种方式实现的单例即使加载了 Singleton 类，也不一定会创建 Singleton 实例，因为 Singleton 的静态引用放到了静态内部类中，只有静态内部类被加载了，Singleton 实例才会被创建。

如果 Singleton 中对外只暴露了 getInstance 方法，那和饿汉方式无异；如果还暴露了其他的静态方法或字段，那相比饿汉方式，可以更精准的实现延迟加载。

枚举方式

枚举方式实现的单例如下：

1
2
3
4
5
6
7
8
public enum Singleton {

    INSTANCE;

    public static Singleton getInstance() {
        return INSTANCE;
    }
}

这种形式或许我们无从下手，但反编译后就明白了，相当于：

1
2
3
4
5
6
7
8
public class Singleton {

    public static final Singleton INSTANCE;

    static{
        INSTANCE = new Singleton();
    }
}

可以看到，枚举方式实现的单例和饿汉方式差不多，延迟加载时机依赖类加载时机。

这里需要搞清楚被 static、final 修饰的编译期常量、运行期常量。

线程安全

这部分内容其实十分简单。

类加载的逻辑位于 synchronized 代码块中，是线程安全的，而饿汉、静态内部类以及枚举方式实现的单例初始化都处于类加载时机，所以它们都是线程安全的。

懒汉方式的初始化与类加载时机无关，所以要自行保证线程安全。

序列化

我们期望单例模式可以实现只创建一个实例，通过特殊手段创建出其他的实例，就对单例模式造成了破坏，序列化就会破坏单例模式。

假如我们的单例实现了 serializable 接口，序列化时会通过反射调用无参数的构造方法创建一个新的实例，这时就要重写 readResolve 方法防止序列化破坏单例，如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
public class Singleton implements Serializable {

    private static class SingletonHolder {
        private static final Singleton INSTANCE = new Singleton();
    }

    private Singleton() {
    }

    public static Singleton getInstance() {
        return SingletonHolder.INSTANCE;
    }

    //防止序列化破坏单例模式
    public Object readResolve() {
        return SingletonHolder.INSTANCE;
    }
}

普通的 Java 类的反序列化过程中，会通过反射创建新的实例。而枚举在序列化的时候仅是将枚举对象的 name 属性输出到结果中，反序列化的时候则是通过 java.lang.Enum 的 valueOf 方法来根据名字查找枚举对象。同时，编译器是不允许任何对这种序列化机制的定制的，禁用了writeObject、readObject、readObjectNoData、writeReplace 和 readResolve 等方法。

枚举的反序列化并不是通过反射实现的，所以也就不会发生由于反序列化导致的单例破坏问题。

Q&A

最后集中回答下开头的问题：

  • 饿汉方式单例到底有多“饿”？
    大多数情况下，饿汉方式同懒汉方式一样时延迟加载的
  • 静态内部类为什么是延迟加载的？
    依赖类加载机制，加载静态内部类时才会初始化
  • 枚举方式单例是延迟加载的吗？
    与饿汉方式类似，类加载时初始化
  • 饿汉、静态内部类、枚举方式单例为什么是线程安全的？
    因为它们在类加载时初始化，而类加载是线程安全的
  • 序列化为什么会破坏单例模式？
    普通的 Java 类的反序列化过程中，会通过反射创建新的实例
  • 怎么防止序列化破坏单例模式？
    使用枚举或重写 readResolve 方法
  • 枚举方式单例是怎么避免序列化破坏的？
    依赖枚举自身特殊的序列化机制
参考：

单例与序列化的那些事儿
为什么我墙裂建议大家使用枚举来实现单例
深度分析Java的枚举类型—-枚举的线程安全性及序列化问题
stackoverflow：singleton-via-enum-way-is-lazy-initialized