資訊專欄INFORMATION COLUMN
摘要：雙重檢查鎖定以下稱為已被廣泛當(dāng)做多線程環(huán)境下延遲初始化的一種高效手段。由于沒有對這些做出明確規(guī)定，很難說是否有效。可以在中使用顯式的內(nèi)存屏障來使生效，但中并沒有這些屏障。如果改變鎖釋放的語義釋放時執(zhí)行一個雙向的內(nèi)存屏障將會帶來性能損失。
雙重檢查鎖定（以下稱為DCL）已被廣泛當(dāng)做多線程環(huán)境下延遲初始化的一種高效手段。
遺憾的是，在Java中，如果沒有額外的同步，它并不可靠。在其它語言中，如c++，實現(xiàn)DCL，需要依賴于處理器的內(nèi)存模型、編譯器實行的重排序以及編譯器與同步庫之間的交互。由于c++沒有對這些做出明確規(guī)定，很難說DCL是否有效。可以在c++中使用顯式的內(nèi)存屏障來使DCL生效，但Java中并沒有這些屏障。
// Single threaded version
class Foo {
private Helper helper = null;
public Helper getHelper() {
if (helper == null)
helper = new Helper();
return helper;
}
// other functions and members...
}
如果這段代碼用在多線程環(huán)境下，有幾個可能出錯的地方。最明顯的是，可能會創(chuàng)建出兩或多個Helper對象。（后面會提到其它問題）。將getHelper()方法改為同步即可修復(fù)此問題。
// Correct multithreaded version
class Foo {
private Helper helper = null;
public synchronized Helper getHelper() {
if (helper == null)
helper = new Helper();
return helper;
}
// other functions and members...
}
上面的代碼在每次調(diào)用getHelper時都會執(zhí)行同步操作。DCL模式旨在消除helper對象被創(chuàng)建后還需要的同步。
// Broken multithreaded version
// "Double-Checked Locking" idiom
class Foo {
private Helper helper = null;
public Helper getHelper() {
if (helper == null)
synchronized(this) {
if (helper == null)
helper = new Helper();
}
return helper;
}
// other functions and members...
}
不幸的是，這段代碼無論是在優(yōu)化型的編譯器下還是在共享內(nèi)存處理器中都不能有效工作。
不起作用上面代碼不起作用的原因有很多。接下來我們先說幾個比較顯而易見的原因。理解這些之后，也許你想找出一種方法來“修復(fù)”DCL模式。你的修復(fù)也不會起作用：這里面有很微妙的原因。在理解了這些原因之后，可能想進一步進行修復(fù)，但仍不會正常工作，因為存在更微妙的原因。
很多聰明的人在這上面花費了很多時間。除了在每個線程訪問helper對象時執(zhí)行鎖操作別無他法。
不起作用的第一個原因最顯而易見的原因是，Helper對象初始化時的寫操作與寫入helper字段的操作可以是無序的。這樣的話，如果某個線程調(diào)用getHelper()可能看到helper字段指向了一個Helper對象，但看到該對象里的字段值卻是默認(rèn)值，而不是在Helper構(gòu)造方法里設(shè)置的那些值。
如果編譯器將調(diào)用內(nèi)聯(lián)到構(gòu)造方法中，那么，如果編譯器能證明構(gòu)造方法不會拋出異常或執(zhí)行同步操作，初始化對象的這些寫操作與hepler字段的寫操作之間就能自由的重排序。
即便編譯器不對這些寫操作重排序，在多處理器上，某個處理器或內(nèi)存系統(tǒng)也可能重排序這些寫操作，運行在其它
處理器上的線程就可能看到重排序帶來的結(jié)果。
Doug Lea寫了一篇更詳細的有關(guān)編譯器重排序的文章。
Paul Jakubik找到了一個使用DCL不能正常工作的例子。下面的代碼做了些許整理：
public class DoubleCheckTest
{
// static data to aid in creating N singletons
static final Object dummyObject = new Object(); // for reference init
static final int A_VALUE = 256; // value to initialize "a" to
static final int B_VALUE = 512; // value to initialize "b" to
static final int C_VALUE = 1024;
static ObjectHolder[] singletons; // array of static references
static Thread[] threads; // array of racing threads
static int threadCount; // number of threads to create
static int singletonCount; // number of singletons to create
static volatile int recentSingleton;
// I am going to set a couple of threads racing,
// trying to create N singletons. Basically the
// race is to initialize a single array of
// singleton references. The threads will use
// double checked locking to control who
// initializes what. Any thread that does not
// initialize a particular singleton will check
// to see if it sees a partially initialized view.
// To keep from getting accidental synchronization,
// each singleton is stored in an ObjectHolder
// and the ObjectHolder is used for
// synchronization. In the end the structure
// is not exactly a singleton, but should be a
// close enough approximation.
//
// This class contains data and simulates a
// singleton. The static reference is stored in
// a static array in DoubleCheckFail.
static class Singleton
{
public int a;
public int b;
public int c;
public Object dummy;
public Singleton()
{
a = A_VALUE;
b = B_VALUE;
c = C_VALUE;
dummy = dummyObject;
}
}
static void checkSingleton(Singleton s, int index)
{
int s_a = s.a;
int s_b = s.b;
int s_c = s.c;
Object s_d = s.dummy;
if(s_a != A_VALUE)
System.out.println("[" + index + "] Singleton.a not initialized " +
s_a);
if(s_b != B_VALUE)
System.out.println("[" + index
+ "] Singleton.b not intialized " + s_b);
if(s_c != C_VALUE)
System.out.println("[" + index
+ "] Singleton.c not intialized " + s_c);
if(s_d != dummyObject)
if(s_d == null)
System.out.println("[" + index
+ "] Singleton.dummy not initialized,"
+ " value is null");
else
System.out.println("[" + index
+ "] Singleton.dummy not initialized,"
+ " value is garbage");
}
// Holder used for synchronization of
// singleton initialization.
static class ObjectHolder
{
public Singleton reference;
}
static class TestThread implements Runnable
{
public void run()
{
for(int i = 0; i < singletonCount; ++i)
{
ObjectHolder o = singletons[i];
if(o.reference == null)
{
synchronized(o)
{
if (o.reference == null) {
o.reference = new Singleton();
recentSingleton = i;
}
// shouldn"t have to check singelton here
// mutex should provide consistent view
}
}
else {
checkSingleton(o.reference, i);
int j = recentSingleton-1;
if (j > i) i = j;
}
}
}
}
public static void main(String[] args)
{
if( args.length != 2 )
{
System.err.println("usage: java DoubleCheckFail" +
" ");
}
// read values from args
threadCount = Integer.parseInt(args[0]);
singletonCount = Integer.parseInt(args[1]);
// create arrays
threads = new Thread[threadCount];
singletons = new ObjectHolder[singletonCount];
// fill singleton array
for(int i = 0; i < singletonCount; ++i)
singletons[i] = new ObjectHolder();
// fill thread array
for(int i = 0; i < threadCount; ++i)
threads[i] = new Thread( new TestThread() );
// start threads
for(int i = 0; i < threadCount; ++i)
threads[i].start();
// wait for threads to finish
for(int i = 0; i < threadCount; ++i)
{
try
{
System.out.println("waiting to join " + i);
threads[i].join();
}
catch(InterruptedException ex)
{
System.out.println("interrupted");
}
}
System.out.println("done");
}
}
當(dāng)上述代碼運行在使用Symantec JIT的系統(tǒng)上時，不能正常工作。尤其是，Symantec
JIT將
singletons[i].reference = new Singleton();
編譯成了下面這個樣子（Symantec JIT用了一種基于句柄的對象分配系統(tǒng)）。
0206106A mov eax,0F97E78h
0206106F call 01F6B210 ; allocate space for
; Singleton, return result in eax
02061074 mov dword ptr [ebp],eax ; EBP is &singletons[i].reference
; store the unconstructed object here.
02061077 mov ecx,dword ptr [eax] ; dereference the handle to
; get the raw pointer
02061079 mov dword ptr [ecx],100h ; Next 4 lines are
0206107F mov dword ptr [ecx+4],200h ; Singleton"s inlined constructor
02061086 mov dword ptr [ecx+8],400h
0206108D mov dword ptr [ecx+0Ch],0F84030h
如你所見，賦值給singletons[i].reference的操作在Singleton構(gòu)造方法之前做掉了。在現(xiàn)有的Java內(nèi)存模型下這完全是允許的，在c和c++中也是合法的（因為c/c++都沒有內(nèi)存模型(譯者注：這篇文章寫作時間較久，c++11已經(jīng)有內(nèi)存模型了)）。
基于前文解釋的原因，一些人提出了下面的代碼：
// (Still) Broken multithreaded version
// "Double-Checked Locking" idiom
class Foo {
private Helper helper = null;
public Helper getHelper() {
if (helper == null) {
Helper h;
synchronized(this) {
h = helper;
if (h == null)
synchronized (this) {
h = new Helper();
} // release inner synchronization lock
helper = h;
}
}
return helper;
}
// other functions and members...
}
將創(chuàng)建Helper對象的代碼放到了一個內(nèi)部的同步塊中。直覺的想法是，在退出同步塊的時候應(yīng)該有一個內(nèi)存屏障，這會阻止Helper的初始化與helper字段賦值之間的重排序。
很不幸，這種直覺完全錯了。同步的規(guī)則不是這樣的。monitorexit（即，退出同步塊）的規(guī)則是，在monitorexit前面的action必須在該monitor釋放之前執(zhí)行。但是，并沒有哪里有規(guī)定說monitorexit后面的action不可以在monitor釋放之前執(zhí)行。因此，編譯器將賦值操作helper = h;挪到同步塊里面是非常合情合理的，這就回到了我們之前說到的問題上。許多處理器提供了這種單向的內(nèi)存屏障指令。如果改變鎖釋放的語義
—— 釋放時執(zhí)行一個雙向的內(nèi)存屏障 —— 將會帶來性能損失。
可以做些事情迫使寫操作的時候執(zhí)行一個雙向的內(nèi)存屏障。這是非常重量級和低效的，且?guī)缀蹩梢钥隙ㄒ坏㎎ava內(nèi)存模型修改就不能正確工作了。不要這么用。如果對此感興趣，我在另一個網(wǎng)頁上描述了這種技術(shù)。不要使用它。
但是，即使初始化helper對象的線程用了雙向的內(nèi)存屏障，仍然不起作用。
問題在于，在某些系統(tǒng)上，看到helper字段是非null的線程也需要執(zhí)行內(nèi)存屏障。
為何？因為處理器有自己本地的對內(nèi)存的緩存拷貝。在有些處理器上，除非處理器執(zhí)行一個cache coherence指令（即，一個內(nèi)存屏障），否則讀操作可能從過期的本地緩存拷貝中取值，即使其它處理器使用了內(nèi)存屏障將它們的寫操作寫回了內(nèi)存。
我開了另一個頁面來討論這在Alpha處理器上是如何發(fā)生的。
值得費這么大勁嗎？對于大部分應(yīng)用來說，將getHelper()變成同步方法的代價并不高。只有當(dāng)你知道這確實造成了很大的應(yīng)用開銷時才應(yīng)該考慮這種細節(jié)的優(yōu)化。
通常，更高級別的技巧，如，使用內(nèi)部的歸并排序，而不是交換排序（見SPECJVM DB的基準(zhǔn)），帶來的影響更大。
如果你要創(chuàng)建的是static單例對象（即，只會創(chuàng)建一個Helper對象），這里有個簡單優(yōu)雅的解決方案。
只需將singleton變量作為另一個類的靜態(tài)字段。Java的語義保證該字段被引用前是不會被初始化的，且任一訪問該字段的線程都會看到由初始化該字段所引發(fā)的所有寫操作。
class HelperSingleton {
static Helper singleton = new Helper();
}
對32位的基本類型變量DCL是有效的
雖然DCL模式不能用于對象引用，但可以用于32位的基本類型變量。注意，DCL也不能用于對long和double類型的基本變量，因為不能保證未同步的64位基本變量的讀寫是原子操作。
// Correct Double-Checked Locking for 32-bit primitives
class Foo {
private int cachedHashCode = 0;
public int hashCode() {
int h = cachedHashCode;
if (h == 0)
synchronized(this) {
if (cachedHashCode != 0) return cachedHashCode;
h = computeHashCode();
cachedHashCode = h;
}
return h;
}
// other functions and members...
}
事實上，如果computeHashCode方法總是返回相同的結(jié)果且沒有其它附屬作用時（即，computeHashCode是個冪等方法），甚至可以消除這里的所有同步。
// Lazy initialization 32-bit primitives
// Thread-safe if computeHashCode is idempotent
class Foo {
private int cachedHashCode = 0;
public int hashCode() {
int h = cachedHashCode;
if (h == 0) {
h = computeHashCode();
cachedHashCode = h;
}
return h;
}
// other functions and members...
}
用顯式的內(nèi)存屏障使DCL有效
如果有顯式的內(nèi)存屏障指令可用，則有可能使DCL生效。例如，如果你用的是C++，可以參考來自Doug
Schmidt等人所著書中的代碼：
