java雙重檢查鎖單例真的線程安全嗎？

相信大多數(shù)同學(xué)在面試當(dāng)中都遇到過手寫單例模式的題目，那么如何寫一個完美的單例是面試者需要深究的問題，因為一個嚴(yán)謹(jǐn)?shù)膯卫Ｊ秸f不定就直接決定了面試結(jié)果，今天我們就要來講講看似線程安全的雙重檢查鎖單例模式中可能會出現(xiàn)的指令重排問題。

雙重檢查鎖單例模式

乍一看下面單例模式?jīng)]啥問題，還加了同步鎖保證線程安全，從表面上看確實看不出啥問題，當(dāng)在同一時間多個線程同時執(zhí)行該單例時就會出現(xiàn)JVM指令重排的問題，從而可能導(dǎo)致某一個線程獲取的single對象未初始化對象。

public class Single { private static Single single; private Single() {
 } public static Single getInstance() { if(null == single) { synchronized (Single.class) { if(null == single) {
     single = new Single();
    }
   }
  } return single;
 }
}

問題前因后果

其實single = new Single()這段代碼并不具備原子性，從代碼層面上來說確實沒問題，但是如果了解JVM指令的就知道其實在執(zhí)行這句代碼的時候在JVM中是需要執(zhí)行三個指令來完成的，如下：

//1：分配對象的內(nèi)存空間 memory = allocate(); //2：初始化對象 ctorInstance(memory); //3：設(shè)置instance指向剛分配的內(nèi)存地址 instance = memory;

看到上面指令重排的解釋之后，那么我們來回顧一下未加volatile修飾符的單例為何會出現(xiàn)問題。假設(shè)有A、B兩個線程去調(diào)用該單例方法，當(dāng)A線程執(zhí)行到single = new Single()時，如果編譯器和處理器對指令重新排序，指令重排后：

//1：分配對象的內(nèi)存空間 memory = allocate(); //3：設(shè)置instance指向剛分配的內(nèi)存地址，此時對象還沒被初始化 instance = memory; //2：初始化對象 ctorInstance(memory);

當(dāng)A線程執(zhí)行到第二步（3：設(shè)置instance指向剛分配的內(nèi)存地址，此時對象還沒被初始化）變量single指向內(nèi)存地址之后就不為null了，此時B線程進(jìn)入第一個if，由于single已經(jīng)不為null了，那么就不會執(zhí)行到同步代碼塊，而是直接返回未初始化對象的變量single，從而導(dǎo)致后續(xù)代碼報錯。

解決方案

問題也搞清楚了，接下來我們就來看下如何解決這個問題。

解決問題的關(guān)鍵就在于volatile關(guān)鍵字，我們來看下volatile關(guān)鍵字的特性。

可見性：

- 寫volatile修飾的變量時，JMM會把本地內(nèi)存中值刷新到主內(nèi)存 讀

-  volatile修飾的變量時，JMM會設(shè)置本地內(nèi)存無效

有序性：

要避免指令重排序，synchronized、lock作用的代碼塊自然是有序執(zhí)行的，volatile關(guān)鍵字有效的禁止了指令重排序，實現(xiàn)了程序執(zhí)行的有序性；

看完volatile關(guān)鍵字的特性之后我們應(yīng)該就明白了，是volatile關(guān)鍵字禁止了指令重排序從而解決了指令重排的問題。

更正后的單例

對比上面單例，下面單例在私有靜態(tài)變量single前面加了修飾符volatile能夠防止JVM指令重排，從而解決了single對象可能出現(xiàn)成員變量未初始化的問題。

public class Single { private volatile static Single single; private Single() {
 } public static Single getInstance() { if(null == single) { synchronized (Single.class) { if(null == single) {
     single = new Single();
    }
   }
  } return single;
 }
}