Java雙重檢查鎖單例真的線程安全嗎?
相信大多數同學在面試當中都遇到過手寫單例模式的題目,那么如何寫一個完美的單例是面試者需要深究的問題,因為一個嚴謹的單例模式說不定就直接決定了面試結果,今天我們就要來講講看似線程安全的雙重檢查鎖單例模式中可能會出現的指令重排問題。
雙重檢查鎖單例模式
乍一看下面單例模式沒啥問題,還加了同步鎖保證線程安全,從表面上看確實看不出啥問題,當在同一時間多個線程同時執行該單例時就會出現JVM指令重排的問題,從而可能導致某一個線程獲取的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指令的就知道其實在執行這句代碼的時候在JVM中是需要執行三個指令來完成的,如下:
- //1:分配對象的內存空間
- memory = allocate();
- //2:初始化對象
- ctorInstance(memory);
- //3:設置instance指向剛分配的內存地址
- instance = memory;
看到上面指令重排的解釋之后,那么我們來回顧一下未加volatile修飾符的單例為何會出現問題。假設有A、B兩個線程去調用該單例方法,當A線程執行到single = new Single()時,如果編譯器和處理器對指令重新排序,指令重排后:
- //1:分配對象的內存空間
- memory = allocate();
- //3:設置instance指向剛分配的內存地址,此時對象還沒被初始化
- instance = memory;
- //2:初始化對象
- ctorInstance(memory);
當A線程執行到第二步(3:設置instance指向剛分配的內存地址,此時對象還沒被初始化)變量single指向內存地址之后就不為null了,此時B線程進入第一個if,由于single已經不為null了,那么就不會執行到同步代碼塊,而是直接返回未初始化對象的變量single,從而導致后續代碼報錯。
解決方案
問題也搞清楚了,接下來我們就來看下如何解決這個問題。解決問題的關鍵就在于volatile關鍵字,原因就在于它的可見性:
寫volatile修飾的變量時,JMM會把本地內存中值刷新到主內存 讀
volatile修飾的變量時,JMM會設置本地內存無效
在多線程環境下,一個線程對共享變量的操作對其他線程是不可見的,Java提供了volatile來保證可見性,當一個變量被volatile修飾后,表示著線程本地內存無效,當一個線程修改共享變量后他會立即被更新到主內存中,其他線程讀取共享變量時,會直接從主內存中讀取。
當然,synchronize和Lock都可以保證可見性,synchronized和Lock能保證同一時刻只有一個線程獲取鎖然后執行同步代碼,并且在釋放鎖之前會將對變量的修改刷新到主存當中。
更正后的單例
對比上面單例,下面單例在私有靜態變量single前面加了修飾符volatile能夠防止JVM指令重排,從而解決了single對象可能出現成員變量未初始化的問題。
- 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;
- }
- }