双重检查锁定

单例创建模式是一个通用的编程习语。和多线程一起使用时，必需使用某种类型的同步。在努力创建更有效的代码时，Java 程序员们创建了双重检查锁定习语，将其和单例创建模式一起使用，从而限制同步代码量。然而，由于一些不太常见的 Java 内存模型细节的原因，并不能保证这个双重检查锁定习语有效。它偶尔会失败，而不是总失败。此外，它失败的原因并不明显，还包含 Java 内存模型的一些隐秘细节。这些事实将导致代码失败，原因是双重检查锁定难于跟踪。在本文余下的部分里，我们将详细介绍双重检查锁定习语，从而理解它在何处失效。

单例创建习语

要理解双重检查锁定习语是从哪里起源的，就必须理解通用单例创建习语，如清单 1 中的阐释：

//清单 1. 单例创建习语   
import java.util.*;  
class Singleton  
{  
  private static Singleton instance;  
  private Vector v;  
  private boolean inUse;  

  private Singleton()  
  {  
    v = new Vector();  
    v.addElement(new Object());  
    inUse = true;  
  }  

  public static Singleton getInstance()  
  {  
    if (instance == null)          //1  
      instance = new Singleton();  //2  
    return instance;               //3  
  }  
}  

此类的设计确保只创建一个 Singleton 对象。构造函数被声明为 private，getInstance() 方法只创建一个对象。这个实现适合于单线程程序。然而，当引入多线程时，就必须通过同步来保护 getInstance() 方法。如果不保护 getInstance() 方法，则可能返回 Singleton 对象的多个不同的实例。

通过同步 getInstance() 方法从而在同一时间只允许一个线程执行代码，这个问题得以改正，如清单 2 所示：

//清单 2. 线程安全的 getInstance() 方法                       
public static synchronized Singleton getInstance()  
{  
  if (instance == null)          //1  
    instance = new Singleton();  //2  
  return instance;               //3  
}  

清单 2 中的代码针对多线程访问 getInstance() 方法运行得很好。然而，当分析这段代码时，您会意识到只有在第一次调用方法时才需要同步。由于只有第一次调用执行了 //2 处的代码，而只有此行代码需要同步，因此就无需对后续调用使用同步。所有其他调用用于决定 instance 是非 null 的，并将其返回。多线程能够安全并发地执行除第一次调用外的所有调用。尽管如此，由于该方法是 synchronized 的，需要为该方法的每一次调用付出同步的代价，即使只有第一次调用需要同步。

同步的代价在不同的 JVM 间是不同的。在早期，代价相当高。随着更高级的 JVM 的出现，同步的代价降低了，但出入 synchronized 方法或块仍然有性能损失。不考虑 JVM 技术的进步，程序员们绝不想不必要地浪费处理时间。

因为只有清单 2 中的 //2 行需要同步，我们可以只将其包装到一个同步块中，如清单 3 所示：

//清单 3. getInstance() 方法                        
public static Singleton getInstance()  
{  
  if (instance == null)  
  {  
    synchronized(Singleton.class) {  
      instance = new Singleton();  
    }  
  }  
  return instance;  
}  

清单 3 中的代码展示了用多线程加以说明的和清单 1 相同的问题。当 instance 为 null 时，两个线程可以并发地进入 if 语句内部。然后，一个线程进入 synchronized 块来初始化 instance，而另一个线程则被阻断。当第一个线程退出 synchronized 块时，等待着的线程进入并创建另一个 Singleton 对象。注意：当第二个线程进入 synchronized 块时，它并没有检查 instance 是否非 null。

双重检查锁定

为使此方法更为有效，一个被称为双重检查锁定的习语就应运而生了。为处理清单 3 中的问题，我们需要对 instance 进行第二次检查。这就是“双重检查锁定”名称的由来。将双重检查锁定习语应用到清单 3 的结果就是清单 4 。

//清单 4. 双重检查锁定示例                        
public static Singleton getInstance()  
{  
  if (instance == null)  
  {  
    synchronized(Singleton.class) {  //1  
      if (instance == null)          //2  
        instance = new Singleton();  //3  
    }  
  }  
  return instance;  
}  

双重检查锁定背后的理论是：在 //2 处的第二次检查使（如清单 3 中那样）创建两个不同的 Singleton 对象成为不可能。假设有下列事件序列：

线程 1 进入 getInstance() 方法。由于 instance 为 null，线程 1 在 //1 处进入 synchronized 块。

线程 1 被线程 2 预占。

线程 2 进入 getInstance() 方法。由于 instance 仍旧为 null，线程 2 试图获取 //1 处的锁。然而，由于线程 1 持有该锁，线程 2 在 //1 处阻塞。

线程 2 被线程 1 预占。

线程 1 执行，由于在 //2 处实例仍旧为 null，线程 1 还创建一个 Singleton 对象并将其引用赋值给 instance。

线程 1 退出 synchronized 块并从 getInstance() 方法返回实例。

线程 1 被线程 2 预占。

线程 2 获取 //1 处的锁并检查 instance 是否为 null。由于 instance 是非 null 的，并没有创建第二个 Singleton 对象，线程 1 创建的对象被返回。

---

双重检查锁定背后的理论是完美的。不幸地是，现实完全不同。双重检查锁定的问题是：并不能保证它会在单处理器或多处理器计算机上顺利运行。

双重检查锁定失败的问题并不归咎于 JVM 中的实现 bug，而是归咎于 Java 平台内存模型。内存模型允许所谓的“无序写入”，这也是这些习语失败的一个主要原因：

初始化 Singleton 和将对象地址写到instance字段的顺序是不确定的。在某个线程new Singleton()时，在构造方法被调用之前，就为该对象分配了内存空间并将对象的字段设置为默认值。此时就可以将分配的内存地址赋值给instance字段了，然而该对象可能还没有初始化;此时若另外一个线程来调用getInstance，取到的就是状态不正确的对象。

鉴于以上原因，有人可能提出下列解决方案：

public class Singleton {  

    private static Singleton instance = null;  

    private Singleton(){}  



    public static Singleton getInstance() {  

       if(instance == null) {  

           Singleton temp;  

           synchronized(Singleton.class) {  

              temp = instance;  

              if(temp == null) {  

                  synchronized(Singleton.class) {  

                     temp = new Singleton();  

                  }  

                  instance = temp;  

              }  

           }  

       }  

       return instance;  

    }  

}  

该方案将Singleton对象的构造置于最里面的同步块，这种思想是在退出该同步块时设置一个内存屏障，以阻止初始化Singleton 和将对象地址写到instance字段的重新排序。

不幸的是，这种想法也是错误的，同步的规则不是这样的。退出监视器(退出同步)的规则是：所有在退出监视器前面的动作都必须在释放监视器之前完成。然而，并没有规定说退出监视器之后的动作不能放到退出监视器之前完成。也就是说同步块里的代码必须在退出同步时完成，而同步块后面的代码则可以被编译器或运行时环境移到同步块中执行。

编译器可以合法地，也是合理地，将instance = temp移动到最里层的同步块内，这样就出现了上个版本同样的问题。

在JDK1.5及其后续版本中，扩充了volatile语义，系统将不允许对写入一个volatile变量的操作与其之前的任何读写操作重新排序，也不允许将读取一个volatile变量的操作与其之后的任何读写操作重新排序。

在jdk1.5及其后的版本中，可以将instance 设置成volatile以让双重检查锁定生效，如下：

public class Singleton {  

    private static volatile Singleton instance = null;  

    private Singleton(){}  



    public static Singleton getInstance() {  

       if(instance == null) {  

           synchronized(Singleton.class) {  

              if(instance == null) {  

                  instance = new Singleton();  

              }  

           }  

       }  

       return instance;  

    }  

}  

需要注意的是：在JDK1.4以及之前的版本中，该方式仍然有问题。

---

参考：
http://blog.csdn.net/applepie1/article/details/7265756

http://developer.51cto.com/art/201104/256239.htm