关于双重检查锁定单例模式

记得最近要去的新公司面试题中一道要求实现一个同步块最小的单例模式.

想也没想就顺手写上双重检查锁定单例(以下简称DCL,double check locking)：

 1 public static Singleton getInstance()
 2 {
 3   if (instance == null)
 4   {
 5     synchronized(Singleton.class) {  //1
 6       if (instance == null)          //2
 7         instance = new Singleton();  //3
 8     }
 9   }
   return instance;
 }
 

但今天在看《Effective java》时却大吃了一惊，其中称： 一般情况下,DCL并不能正确的工作。

如此出名的DCL模式居然是错误的！我对这个模式早已经见过多次，在C++中应用得非常好，而《head first design patterns》里面讲单例的章节还专门提出了这个理想的模式。

但《Effective java》是jdk的设计师所写的，可信度不容置疑，于是我带着疑惑去网上查找了相关资料。

然后在IBM的wiki那里找到答案：

http://www.ibm.com/developerworks/cn/java/j-dcl.html

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

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

实际上当java在用new创建一个实例时，如执行 instance = new Singleton()时

过程是如下的(伪代码)：

mem = allocate();             //Allocate memory for Singleton object.
instance = mem;               //Note that instance is now non-null, but
                              //has not been initialized.
ctorSingleton(instance);      //Invoke constructor for Singleton passing
                              //instance.

当执行到第二步时，内存已经分配了，instance引用也已指向新分配内存，而构造函数却还未执行。

在此时，如果另一个线程来check instance时，会发现该instance已经不为null了，于是直接越过同步块，返回instance所引用的构造了一半的实例。这就是导致DCL失败的原因。

另外，我还专门查证了C#是否能使用DCL。得到的结果是：

C#中也存在一样的问题，也就是说DCL在C#中也不可用。