单例的线程安全及序列化问题
单例模式可以说是最简单的设计模式了,但也有一些细节需要注意。本文从几个问题出发,分析一下单例模式的各种姿势,以便在今后使用时游刃有余,面试时从容不迫。
- 饿汉方式到底有多饿?
- 静态内部类为什么是延迟加载的?
- 枚举方式单例是延迟加载的吗?
- 饿汉、静态内部类、枚举方式单例为什么是线程安全的?
- 序列化为什么会破坏单例模式?
- 怎么防止序列化破坏单例模式?
- 枚举方式单例是怎么避免序列化破坏的?
饿汉方式
先来看一下饿汉方式单例:
public class Singleton {
private static Singleton instance = new Singleton();
private Singleton() { }
public static Singleton getInstance() {
return instance;
}
}
饿汉方式往往会跟懒汉方式一起提起,对比而言,懒汉方式具有延迟实例化的优点。这容易让人对饿汉方式有一个恶劣的刻板印象:它的性能很不好,没有使用它的时候它就会初始化,白白占用资源!
来思考一下,饿汉方式单例到底有多“饿”?它到底什么时候会初始化呢?我们知道类加载的时候会初始化静态资源,所以饿汉方式的实例化时机就是类加载时机,回顾一下类加载的时机:
- 使用 new 关键字实例化
- 调用一个类的静态方法
- 读取一个类的静态字段(被 final 修饰已在编译期把结果放在常量池的静态字段除外)
如果你的单例只暴露了 getInstance() 方法,没有其他的 public static 成员或方法,那饿汉方式就同懒汉方式一样都是延迟加载的。
如果你认为只暴露 getInstance() 方法是单例规范的写法,那就放心的使用饿汉方式吧!
如果别人 diss 了你的饿汉方式,那就 diss back 让他去复习类加载机制!
如果别人玷污了你的单例,添加了其他的 public static 方法/字段,那就算了放弃吧...
静态内部类
静态内部类方式单例如下:
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 实例才会被创建。
如果别人在你的 SingletonHolder 中添加了 public static 方法/字段,请一定要下重手。
枚举
枚举方式实现的单例如下:
public enum Singleton {
INSTANCE;
public static Singleton getInstance() {
return INSTANCE;
}
}
这种形式我们无从下手,反编译后就明白了,相当于:
public class Singleton {
public static final Singleton INSTANCE;
static{
INSTANCE = new Singleton();
}
}
可以看到,枚举方式实现的单例和饿汉方式差不多,实例化时机就是类加载时机。
线程安全
类加载的逻辑位于 synchronized 代码块中,是线程安全的,而饿汉、静态内部类以及枚举方式实现的单例实例化都处于类加载时机,所以它们都是线程安全的。
懒汉方式的初始化与类加载时机无关,所以要自行保证线程安全。
序列化
我们期望单例模式可以实现只创建一个实例,通过特殊手段创建出其他的实例,就对单例模式造成了破坏,序列化就会破坏单例模式。
假如我们的单例实现了 serializable 接口,反序列化时会通过反射调用无参构造方法创建一个新的实例,这时就要重写 readResolve 方法防止序列化破坏单例,如下:
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 等方法。
也就是说,枚举的反序列化不是通过反射实现的,所以不会导致单例模式被破坏的问题。
最后总结回答开头提出的问题:
- 饿汉方式到底有多饿? 取决于类什么时候加载
- 静态内部类为什么是延迟加载的? 取决于内部类什么时候加载
- 枚举方式单例是延迟加载的吗? 与饿汉方式一样,取决于类什么时候加载
- 饿汉、静态内部类、枚举方式单例为什么是线程安全的? 因为它们在类加载时实例化,而类加载是线程安全的
- 序列化为什么会破坏单例模式? 普通 Java 类反序列化时,会通过反射创建新的实例
- 怎么防止序列化破坏单例模式? 重写 readResolve 方法或使用枚举
- 枚举方式单例是怎么避免序列化破坏的? 依赖枚举自身特殊的序列化机制

转载自:https://juejin.cn/post/6844904166641369102