Ahab's Studio.

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

字数统计: 1.7k阅读时长: 6 min
2019/03/05 Share

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

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

开始正文前先思考下以上问题,如果你都掌握了,就可以点叉出去了。

延迟加载

饿汉方式

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

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

关注公众号,Get 更多知识点

原文作者:Ahab

原文链接:http://yhaowa.gitee.io/1516a551/

发表日期:March 5th 2019, 11:04:44 pm

更新日期:April 7th 2020, 11:34:42 pm

版权声明:本文采用知识共享署名-非商业性使用 4.0 国际许可协议进行许可

CATALOG
  1. 1. 延迟加载
    1. 1.0.0.1. 饿汉方式
    2. 1.0.0.2. 静态内部类
    3. 1.0.0.3. 枚举方式
  • 2. 线程安全
  • 3. 序列化
  • 4. Q&A
    1. 4.0.0.0.0.1. 参考: