前言
单例模式应该算是 23 种设计模式中,最常见最容易考察的知识点了。经常会有面试官让手写单例模式,别到时候傻乎乎的说我不会。
之前,我有介绍过单例模式的几种常见写法。还不知道的,传送门看这里:
本篇文章将展开一些不太容易想到的问题。带着你思考一下,传统的单例模式有哪些问题,并给出解决方案。让面试官眼中一亮,心道,小伙子有点东西啊!
以下,以 DCL 单例模式为例。
DCL 单例模式
DCL 就是 Double Check Lock 的缩写,即双重检查的同步锁。代码如下,
public class Singleton {
//注意,此变量需要用volatile修饰以防止指令重排序
private static volatile Singleton singleton = null;
private Singleton(){
}
public static Singleton getInstance(){
//进入方法内,先判断实例是否为空,以确定是否需要进入同步代码块
if(singleton == null){
synchronized (Singleton.class){
//进入同步代码块时再次判断实例是否为空
if(singleton == null){
singleton = new Singleton();
}
}
}
return singleton;
}
}
乍看,以上的写法没有什么问题,而且我们确实也经常这样写。
但是,问题来了。
DCL 单例一定能确保线程安全吗?
有的小伙伴就会说,你这不是废话么,大家不都这样写么,肯定是线程安全的啊。
确实,在正常情况,我可以保证调用 getInstance 方法两次,拿到的是同一个对象。
但是,我们知道 Java 中有个很强大的功能——反射。对的,没错,就是他。
通过反射,我就可以破坏单例模式,从而调用它的构造函数,来创建不同的对象。
public class TestDCL {
public static void main(String[] args) throws Exception {
Singleton singleton1 = Singleton.getInstance();
System.out.println(singleton1.hashCode()); // 723074861
Class<Singleton> clazz = Singleton.class;
Constructor<Singleton>

本文探讨了单例模式中的DCL实现,分析了为何DCL并不完全线程安全,以及如何通过反射破坏单例。接着,文章详细解释了如何通过在构造函数中增加判断来防止反射创建多个实例。然而,即使如此,单例仍可能被序列化破坏。作者通过添加`readResolve`方法展示了如何解决这个问题。最后,提到了枚举单例作为防止序列化破坏的另一种方式。
最低0.47元/天 解锁文章
5758

被折叠的 条评论
为什么被折叠?



