单例模式的双重检查锁原理及JIT的无序写入对双重检查锁的破坏（下）

清单8.从清单7中优化来的代码。

publicstaticSingletongetInstance()
{
if(instance==null)
{
synchronized(Singleton.class){//1
Singletoninst=instance;//2
if(inst==null)
{
synchronized(Singleton.class){//3
//inst=newSingleton();//4
instance=newSingleton();
}
//instance=inst;//5
}
}
}
returninstance;
}

如果进行此项优化，您将同样遇到我们之前讨论过的无序写入问题。

用volatile声明每一个变量怎么样？

另一个想法是针对变量inst以及instance使用关键字volatile。根据JLS（参见参考资料），声明成volatile的变量被认为是顺序一致的，即，不是重新排序的。但是试图使用volatile来修正双重检查锁定的问题，会产生以下两个问题：

• 这里的问题不是有关顺序一致性的，而是代码被移动了，不是重新排序。
• 即使考虑了顺序一致性，大多数的JVM也没有正确地实现volatile。

第二点值得展开讨论。假设有清单9中的代码：

清单9.使用了volatile的顺序一致性

classtest
{
privatevolatilebooleanstop=false;
privatevolatileintnum=0;

publicvoidfoo()
{
num=100;//Thiscanhappensecond
stop=true;//Thiscanhappenfirst
//...
}

publicvoidbar()
{
if(stop)
num+=num;//numcan==0!
}
//...
}

根据JLS，由于stop和num被声明为volatile，它们应该顺序一致。这意味着如果stop曾经是true，num一定曾被设置成100。尽管如此，因为许多JVM没有实现volatile的顺序一致性功能，您就不能依赖此行为。因此，如果线程1调用foo并且线程2并发地调用bar，则线程1可能在num被设置成为100之前将stop设置成true。这将导致线程见到stop是true，而num仍被设置成0。使用volatile和64位变量的原子数还有另外一些问题，但这已超出了本文的讨论范围。有关此主题的更多信息，请参阅参考资料。

解决方案

底线就是：无论以何种形式，都不应使用双重检查锁定，因为您不能保证它在任何JVM实现上都能顺利运行。JSR-133是有关内存模型寻址问题的，尽管如此，新的内存模型也不会支持双重检查锁定。因此，您有两种选择：

• 接受如清单2中所示的getInstance()方法的同步。
• 放弃同步，而使用一个static字段。

选择项2如清单10中所示

清单10.使用static字段的单例实现

classSingleton
{
privateVectorv;
privatebooleaninUse;
privatestaticSingletoninstance=newSingleton();

privateSingleton()
{
v=newVector();
inUse=true;
//...
}

publicstaticSingletongetInstance()
{
returninstance;
}
}

清单10的代码没有使用同步，并且确保调用staticgetInstance()方法时才创建Singleton。如果您的目标是消除同步，则这将是一个很好的选择。

String不是不变的

鉴于无序写入和引用在构造函数执行前变成非null的问题，您可能会考虑String类。假设有下列代码：

privateStringstr;
//...
str=newString("hello");

String类应该是不变的。尽管如此，鉴于我们之前讨论的无序写入问题，那会在这里导致问题吗？答案是肯定的。考虑两个线程访问Stringstr。一个线程能看见str引用一个String对象，在该对象中构造函数尚未运行。事实上，清单11包含展示这种情况发生的代码。注意，这个代码仅在我测试用的旧版JVM上会失败。IBM1.3和Sun1.3JVM都会如期生成不变的String。

清单11.可变String的例子

classStringCreatorextendsThread
{
MutableStringms;
publicStringCreator(MutableStringmuts)
{
ms=muts;
}
publicvoidrun()
{
while(true)
ms.str=newString("hello");//1
}
}
classStringReaderextendsThread
{
MutableStringms;
publicStringReader(MutableStringmuts)
{
ms=muts;
}
publicvoidrun()
{
while(true)
{
if(!(ms.str.equals("hello")))//2
{
System.out.println("Stringisnotimmutable!");
break;
}
}
}
}
classMutableString
{
publicStringstr;//3
publicstaticvoidmain(Stringargs[])
{
MutableStringms=newMutableString();//4
newStringCreator(ms).start();//5
newStringReader(ms).start();//6
}
}

此代码在//4处创建一个MutableString类，它包含了一个String引用，此引用由//3处的两个线程共享。在行//5和//6处，在两个分开的线程上创建了两个对象StringCreator和StringReader。传入一个MutableString对象的引用。StringCreator类进入到一个无限循环中并且使用值“hello”在//1处创建String对象。StringReader也进入到一个无限循环中，并且在//2处检查当前的String对象的值是不是“hello”。如果不行，StringReader线程打印出一条消息并停止。如果String类是不变的，则从此程序应当看不到任何输出。如果发生了无序写入问题，则使StringReader看到str引用的惟一方法绝不是值为“hello”的String对象。

在旧版的JVM如SunJDK1.2.1上运行此代码会导致无序写入问题。并因此导致一个非不变的String。

结束语

为避免单例中代价高昂的同步，程序员非常聪明地发明了双重检查锁定习语。不幸的是，鉴于当前的内存模型的原因，该习语尚未得到广泛使用，就明显成为了一种不安全的编程结构。重定义脆弱的内存模型这一领域的工作正在进行中。尽管如此，即使是在新提议的内存模型中，双重检查锁定也是无效的。对此问题最佳的解决方案是接受同步或者使用一个staticfield。