双重检查锁定（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