前言
单例模式应该算是 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.cl