双重检测锁单例模式指令重排问题

前言

相信大多数同学在面试当中都遇到过手写单例模式的题目,那么如何写一个完美的单例是面试者需要深究的问题,因为一个严谨的单例模式说不定就直接决定了面试结果,今天我们就要来讲讲看似线程安全的双重检测锁单例模式中可能会出现的指令重排问题。

双重检测锁单例模式例子

乍一看下面单例模式没啥问题,还加了同步锁保证线程安全,从表面上看确实看不出啥问题,当在同一时间多个线程同事执行该单例时就会出现JVM指令重排的问题,从而可能导致某一个线程获取的single对象未初始化对象。

public class Single {

	private static Single single;
	
	private Single() {
	}
	
	public static Single getInstance() {
		if(null == single) {
			synchronized (Single.class) {
				if(null == single) {
					single = new Single();
				}
			}
		}
		return single;
	}
}

问题前因后果

其实single = new Single()这段代码并不具备原子性,从代码层面上来说确实没问题,但是如果了解JVM指令的就知道其实在执行这句代码的时候在JVM中是需要执行三个指令来完成的,如下:

memory = allocate(); //1:分配对象的内存空间
ctorInstance(memory); //2:初始化对象
instance = memory; //3:设置instance指向刚分配的内存地址

看到上面指令重排的解释之后,那么我们来回顾一下未加volatile修饰符的单例为何会出现问题。
假设有A、B两个线程去调用该单例方法,当A线程执行到single = new Single()时,如果编译器和处理器对指令重新排序,指令重排后:

memory = allocate(); //1:分配对象的内存空间
instance = memory; //3:设置instance指向刚分配的内存地址,此时对象还没被初始化
ctorInstance(memory); //2:初始化对象

当A线程执行到第二步(3:设置instance指向刚分配的内存地址,此时对象还没被初始化)变量single指向内存地址之后就不为null了,此时B线程进入第一个if,由于single已经不为null了,那么就不会执行到同步代码块,而是直接返回未初始化对象的变量single,从而导致后续代码报错。

解决方案

问题也搞清楚了,接下来我们就来看下如何解决这个问题。
解决问题的关键就在于volatile关键字,我们来看下volatile关键字的特性。
可见性:

  • 写volatile修饰的变量时,JMM会把本地内存中值刷新到主内存 读
  • volatile修饰的变量时,JMM会设置本地内存无效

有序性:
要避免指令重排序,synchronized、lock作用的代码块自然是有序执行的,volatile关键字有效的禁止了指令重排序,实现了程序执行的有序性;
看完volatile关键字的特性之后我们应该就明白了,是volatile关键字禁止了指令重排序从而解决了指令重排的问题。

更改后的单例

对比上面单例,下面单例在私有静态变量single前面加了修饰符volatile,能够防止JVM指令重排,从而解决了single对象可能出现成员变量未初始化的问题。

public class Single {

	private volatile static Single single;
	
	private Single() {
	}
	
	public static Single getInstance() {
		if(null == single) {
			synchronized (Single.class) {
				if(null == single) {
					single = new Single();
				}
			}
		}
		return single;
	}
}
### 什么是双重检查锁定中的 `volatile` 关键字及其作用 在 Java 中,`volatile` 是一种特殊的变量修饰符,主要用于多线程环境下的可见性和有序性保障。对于双重检查锁定(Double-Checked Locking, DCL)单例模式而言,`volatile` 的引入解决了因指令重排序而导致的对象“逸出”问题。 #### 1. **可见性** 当多个线程共享同一个变量时,如果没有使用同步机制或者 `volatile`,某个线程对变量的修改可能无法及时被其他线程感知到。这是因为每个线程可能会有自己的本地缓存副本[^1]。通过声明 `instance` 为 `volatile`,可以确保所有线程都能看到最新的值,从而避免某些线程读取到过期数据的情况。 ```java private static volatile Singleton instance = null; ``` 这段代码表明 `instance` 被标记为 `volatile` 后,在任何时刻对其写入的操作都会立即刷新回主内存,并且每次读取都必须从主内存获取最新值[^3]。 --- #### 2. **防止指令重排序** JVM 和 CPU 层面为了提高执行效率,允许对程序语句进行重新排列,只要逻辑上不影响串行结果即可。然而,在创建对象的过程中存在潜在风险: 假设以下伪代码表示了 `new Singleton()` 的过程: ```plaintext memory = allocate(); // 1. 分配对象内存空间 ctorInstance(memory); // 2. 初始化对象 instance = memory; // 3. 设置 instance 指向刚分配的内存地址 ``` 如果发生指令重排序,则可能出现下面这种情况: ```plaintext memory = allocate(); // 1. instance = memory; // 3. (提前暴露未完全初始化的对象) ctorInstance(memory); // 2. ``` 此时另一个线程可能访问到了尚未完成构造函数调用的半成品对象,这显然违反了预期行为[^5]。而加上 `volatile` 就能阻止这种危险的重排现象,强制按照定义顺序依次执行每一步操作。 --- #### 3. **有序性** 除了控制特定字段上的动作外,`happens-before` 原则还规定了一系列规则来维护整体一致性。具体来说,一旦某处设置了带有 `volatile` 特性的变量之后,之前所有的普通写操作都将先于后续对该变量本身的读/写生效;反之亦然——即后面发生的针对此变量的动作不会跑到前面去干扰先前已完成的工作流。 这意味着即使是在复杂的竞争条件下,也能依靠这些约定保持全局状态的一致性而不至于崩溃或陷入死循环等问题之中。 --- ### 结合实际案例分析 考虑典型实现方式如下所示: ```java public class Singleton { private static volatile Singleton instance; private Singleton() {} public static Singleton getInstance() { if (instance == null) { // 第一次检查 synchronized (Singleton.class) { if (instance == null) { // 第二次检查 instance = new Singleton(); } } } return instance; } } ``` 这里的关键在于第三步赋值前后的屏障设置使得整个流程更加稳健可靠。假如缺少这个属性限定的话,就有可能因为上述提到的各种原因造成不可预料的结果甚至系统错误。 --- ### 总结 综上所述,`volatile` 在双重检查锁定单例模式里的主要贡献体现在三个方面:增强跨处理器间通信的有效性(也就是所谓的"可见性")、抑制不必要的编译器优化带来的副作用以及维持必要的因果关系链条以便构建更健壮的应用架构体系结构之上[^3]。 ---
评论 2
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值