为何双重检查锁模式须要 volatile ？

双重检查锁定（Double check locked）模式常常会出如今一些框架源码中，目的是为了延迟初始化变量。这个模式还能够用来建立单例。下面来看一个 Spring 中双重检查锁定的例子。

这个例子中须要将配置文件加载到 handlerMappings中，因为读取资源比较耗时，因此将动做放到真正须要 handlerMappings 的时候。咱们能够看到 handlerMappings 前面使用了volatile 。有没有想过为何必定须要 volatile？虽然以前了解了双重检查锁定模式的原理，可是却忽略变量使用了 volatile。

下面咱们就来看下这背后的缘由。

错误的延迟初始化例子

想到延迟初始化一个变量，最简单的例子就是取出变量进行判断。

这个例子在单线程环境交易正常运行，可是在多线程环境就有可能会抛出空指针异常。为了防止这种状况，咱们须要使用 synchronized 。这样该方法在多线程环境就是安全的，可是这么作就会致使每次调用该方法获取与释放锁，开销很大。

深刻分析能够得知只有在初始化的变量的须要真正加锁，一旦初始化以后，直接返回对象便可。

因此咱们能够将该方法改造如下的样子。

这个方法首先判断变量是否被初始化，没有被初始化，再去获取锁。获取锁以后，再次判断变量是否被初始化。第二次判断目的在于有可能其余线程获取过锁，已经初始化改变量。第二次检查还未经过，才会真正初始化变量。

这个方法检查断定两次，并使用锁，因此形象称为双重检查锁定模式。

这个方案缩小锁的范围，减小锁的开销，看起来很完美。然而这个方案有一些问题却很容易被忽略。

new 实例背后的指令

这个被忽略的问题在于 Cache cache=new Cache() 这行代码并非一个原子指令。使用 javap -c指令，能够快速查看字节码。

// 建立 Cache 对象实例，分配内存
       0: new           #5                  // class com/query/Cache
       // 复制栈顶地址，并再将其压入栈顶
       3: dup
	// 调用构造器方法，初始化 Cache 对象
       4: invokespecial #6                  // Method "<init>":()V
	// 存入局部方法变量表
       7: astore_1
复制代码

从字节码能够看到建立一个对象实例，能够分为三步：

1. 分配对象内存
2. 调用构造器方法，执行初始化
3. 将对象引用赋值给变量。

虚拟机实际运行时，以上指令可能发生重排序。以上代码 2,3 可能发生重排序，可是并不会重排序 1 的顺序。也就是说 1 这个指令都须要先执行，由于 2,3 指令须要依托 1 指令执行结果。

Java 语言规规定了线程执行程序时须要遵照 intra-thread semantics。**intra-thread semantics ** 保证重排序不会改变单线程内的程序执行结果。这个重排序在没有改变单线程程序的执行结果的前提下，能够提升程序的执行性能。

虽然重排序并不影响单线程内的执行结果，可是在多线程的环境就带来一些问题。

上面错误双重检查锁定的示例代码中，若是线程 1 获取到锁进入建立对象实例，这个时候发生了指令重排序。当线程1 执行到 t3 时刻，线程 2 恰好进入，因为此时对象已经不为 Null，因此线程 2 能够自由访问该对象。而后该对象还未初始化，因此线程 2 访问时将会发生异常。

volatile 做用

正确的双重检查锁定模式须要须要使用 volatile。volatile主要包含两个功能。

1. 保证可见性。使用 volatile 定义的变量，将会保证对全部线程的可见性。
2. 禁止指令重排序优化。

因为 volatile 禁止对象建立时指令之间重排序，因此其余线程不会访问到一个未初始化的对象，从而保证安全性。

注意，volatile禁止指令重排序在 JDK 5 以后才被修复

使用局部变量优化性能

从新查看 Spring 中双重检查锁定代码。

能够看到方法内部使用局部变量，首先将实例变量值赋值给该局部变量，而后再进行判断。最后内容先写入局部变量，而后再将局部变量赋值给实例变量。

使用局部变量相对于不使用局部变量，能够提升性能。主要是因为 volatile 变量建立对象时须要禁止指令重排序，这就须要一些额外的操做。

总结

对象的建立可能发生指令的重排序，使用 volatile 能够禁止指令的重排序，保证多线程环境内的系统安全。

帮助文档

双重检查锁定与延迟初始化
有关“双重检查锁定失效”的说明