1.双重检查锁定的由来
下面是非线程安全的延迟初始化对象的示例代码。
public class UnsafeLazyInitialization {
private static Instance instance;
public static Instance getInstance(){
if(instance ==null) //1:A线程执行
instance = new Instance(); //2:B线程执行
return instance;
}
}
在UnsafeLazyInitialization类中，假设A线程执行代码1的同时，B线程执行代码2。此时，线程A可能会看到instance引用的对象还没有完成初始化（原因之后分析）
对于UnsafeLazyInitialization类，我们可以对getInstance()方法做同步处理来实现线程安全的延迟初始化。示例代码如下。
public class safeLazyInitialization {
private static Instance instance;
public synchronized static Instance getInstance(){
if(instance ==null)
instance = new Instance();
return instance;
}
}
由于对getInstance()方法做了同步处理，synchronized将导致性能开销。如果getInstance（）被多个线程调用，将导致程序性能下降。反之，那么这个延迟初始化方案能提供令人满意的性能。
在早期的JVM中，synchronized（甚至是无竞争的synchronized）存在着巨大性能开销。因此，出现双重检查锁定。以下是示例代码。
public class DoubleCheckedLocking { //1
private static Instance instance; //2
public static Instance getInstance(){ //3
if(instance ==null) { //4:第一次检查
synchronized (DoubleCheckedLocking.class) { //5：加锁
if (instance == null) //6：第二次检查
instance = new Instance(); //7：问题的根源处在这里
} //8
} //9
return instance; //10
} //11
}
如上面的代码所示，如果第一次检查instance不为null，那就不需要执行下面的加锁和初始化操作。因此，可以大幅降低synchronized带来的性能开销。
这样似乎很完美，但这是一个错误的优化！在线程执行到第4行，代码读取到instance不为null时，instance引用的对象可能还没有完成初始化。
2.问题的根源
前面的双重检查示例代码第7行创建了一个对象。这一行代码可以分解为如下的3行伪代码。
memory=allocate(); //1:分配对象的内存空间
ctorInstance(memory); //2:初始化对象
instance = memory; //3:设置instance指向刚分配的内存地址
上面3行伪代码中的2和3之间，可能会被重排序。2和3重排序之后的执行时序如下。
memory=allocate(); //1:分配对象的内存空间
instance = memory; //3:设置instance指向刚分配的内存地址
//注意，此时对象还没有被初始化！
ctorInstance(memory); //2:初始化对象
由于单线程内要遵守intra-thread semantics,从而能保证A线程的执行结果不会被改变。但是，当线程A和B按上图时序执行时，B线程将看到一个还没有被初始化的对象。
回到主题，DoubleCheckedLocking代码第7行（instance=new Instance()；）如果发生重排序，拎一个并发执行的线程B就有可能在第4行判断instance不为null。线程B接下来访问instance所引用的对象，但此时这个对象可能还没有被A线程初始化！
在知晓了问题发生的根源之后，我们可以想出两个办法来实现线程安全的延迟初始化。
1.不允许2和3重排序
2.允许2和3重排序，但不允许其他线程“看到”这个重排序。
基于上面这两点，提出两个解决方案。
3.1基于volatile的解决方案
对于前面的基于双重检查锁定来实现延迟初始化的方案，只需要做一点小的修改（把instance声明为volatile型），就可以实现线程安全的延迟初始化。请看下面的示例代码。
public class SafeDoubleCheckedLocking {
private volatile static Instance instance;
public static Instance getInstance(){
if(instance ==null) {
synchronized (SafeDoubleCheckedLocking.class) {
if (instance == null)
instance = new Instance(); //instance为volatile，现在没问题了
}
}
return instance;
}
}
当声明对象的引用为volatile后，之前的3行伪代码中的2和3之间的重排序，在多线程环境中将会被禁止。上面的示例代码江安如下的时序执行。
这个方案是通过禁止上图2和3之间的重排序，来保证线程安全的延迟初始化。
3.2基于类初始化的解决方案
JVM在类的初始化阶段（即在Class被加载后，且被线程使用之前），会执行类的初始化。在执行类的初始化期间，JVM会去获取一个锁。这个锁可以同步多个线程对同一个类的初始化。
基于这个特性可以实现另一种线程安全的延迟初始化方案。
public class InstanceFactory{
private static class InstanceHolder{
public static Instance instance = new Instance();
}
public static Instance getInstance(){
return InstanceHolder.instance; //这里将导致InstanceHolder类被初始化
}
}
假设两个线程并发执行getInstance（）方法，下面是执行示意图。
这个方案的实质是：允许之前的3行伪代码中的2和3重排序，但不允许非构造线程（这里指线程B）“看到”这个重排序。
4.总结
通过对比基于volatile的双重检查锁定的方案和基于类初始化的方案，我们会发现基于类初始化的方案的实现代码更简洁。但基于volatile的双重检查锁定的方案有一个额外的优势：除了可以对静态字段实现延迟初始化外，还可以对实例字段实现延迟初始化。
字段延迟初始化降低了初始化类或创建实例的开销，但增加了访问被延迟初始化的字段的开销。在大多数时候，正常的初始化要优于延迟初始化。如果确实需要对实例字段使用线程安全的延迟初始化，请使用上面介绍的基于volatile的延迟初始化方案；如果确实需要对静态字段使用线程安全的延迟初始化，请使用基于类初始化的方案。
——摘自《Java并发编程的艺术》
