你寫的單例模式有空指針異常,請(qǐng)用Volatile改一下……
1 單例模式
大家對(duì)單例模式并不會(huì)陌生,當(dāng)創(chuàng)建一個(gè)對(duì)象需要消耗比較多資源時(shí),例如創(chuàng)建數(shù)據(jù)庫(kù)連接和消息服務(wù)端等等,這時(shí)我們選擇只創(chuàng)建一份這種類型的對(duì)象并在進(jìn)程內(nèi)共享。
但是單例模式想要寫好并不容易,我們寫多個(gè)版本的單例模式看看每個(gè)版本都有什么問(wèn)題。
1.1 版本一
這個(gè)版本問(wèn)題非常明顯:多個(gè)線程可能同時(shí)執(zhí)行到語(yǔ)句1,而此時(shí)myConnection都為空,造成連接對(duì)象被多次創(chuàng)建。
public?class?MySimpleConnection?{
????private?static?MySimpleConnection?myConnection?=?null;
????private?MySimpleConnection()?{
????????System.out.println(Thread.currentThread().getName()?+?"?->?init?connection");
????}
????public?static?MySimpleConnection?getConnection()?{
????????if?(null?==?myConnection)?{?//?語(yǔ)句1
????????????myConnection?=?new?MySimpleConnection();
????????}
????????return?myConnection;
????}
????public?static?void?main(String[]?args)?{
????????for?(int?i?=?0;?i?10;?i++)?{
????????????new?Thread(()?->?{
????????????????MySimpleConnection.getConnection();
????????????},?"threadName"?+?i).start();
????????}
????}
}
執(zhí)行結(jié)果可以看出連接被創(chuàng)建多次:
threadName1?->?init?connection
threadName4?->?init?connection
threadName3?->?init?connection
threadName2?->?init?connection
threadName0?->?init?connection
1.2 版本二
這個(gè)版本在getConnection方法增加了同步關(guān)鍵字,可以正確處理同步問(wèn)題,程序執(zhí)行正確符合預(yù)期,但是將同步關(guān)鍵詞加在方法上鎖粒度較大,可能會(huì)影響性能。
public?class?MySynchronizeConnection?{
????private?static?MySynchronizeConnection?myConnection?=?null;
????private?MySynchronizeConnection()?{
????????System.out.println(Thread.currentThread().getName()?+?"?->?init?connection");
????}
????public?static?synchronized?MySynchronizeConnection?getConnection()?{
????????if?(null?==?myConnection)?{
????????????myConnection?=?new?MySynchronizeConnection();
????????}
????????return?myConnection;
????}
????public?static?void?main(String[]?args)?{
????????for?(int?i?=?0;?i?10;?i++)?{
????????????new?Thread(()?->?{
????????????????MySynchronizeConnection.getConnection();
????????????},?"threadName"?+?i).start();
????????}
????}
}
執(zhí)行結(jié)果正確符合預(yù)期:
threadName0?->?init?connection
1.3 版本三
這個(gè)版本采用DCL(Double Check lock)雙重檢查鎖,縮小了同步鎖粒度,性能會(huì)有所提升。
public?class?MyDCLConnection?{
????private?static?MyDCLConnection?myConnection?=?null;
????private?MyDCLConnection()?{
????????System.out.println(Thread.currentThread().getName()?+?"?->?init?connection");
????}
????public?static?MyDCLConnection?getConnection()?{
????????if?(null?==?myConnection)?{
????????????synchronized?(MyDCLConnection.class)?{
????????????????if?(null?==?myConnection)?{
????????????????????myConnection?=?new?MyDCLConnection();
????????????????}
????????????}
????????}
????????return?myConnection;
????}
????public?static?void?main(String[]?args)?{
????????for?(int?i?=?0;?i?10;?i++)?{
????????????new?Thread(()?->?{
????????????????MyDCLConnection.getConnection();
????????????},?"threadName"?+?i).start();
????????}
????}
}
這段代碼看似沒有問(wèn)題了,但是其實(shí)有一個(gè)嚴(yán)重問(wèn)題:這段代碼有可能引發(fā)空指針異常,也就是調(diào)用getConnection方法會(huì)拿到一個(gè)空對(duì)象。
你可能會(huì)說(shuō)不對(duì),我們不是判斷了當(dāng)連接不為空時(shí)才獲取連接嗎?怎么會(huì)拿到一個(gè)空對(duì)象呢?這就引出我們下一個(gè)話題:指令重排。
2 指令重排
在JVM編譯代碼時(shí)或者CPU執(zhí)行JVM字節(jié)碼時(shí),為了提升性能可能對(duì)代碼進(jìn)行指令重排,也就是說(shuō)代碼執(zhí)行順序不一定是代碼編寫順序。
指令重排目的是為了在不改變程序運(yùn)行結(jié)果的前提下,優(yōu)化程序運(yùn)行效率,其中不改變運(yùn)行結(jié)果是指在單線程場(chǎng)景下。
我們分析一個(gè)指令重排實(shí)例。
public?void?test()?{
????int?a?=?1;?//?語(yǔ)句1
????int?b?=?2;?//?語(yǔ)句2
????a?=?a?+?1;?//?語(yǔ)句3
????b?=?b?*?2;?//?語(yǔ)句4
}
這段代碼執(zhí)行順序可能如下:
1234
1243
1324
2134
2143
2413
我們思考一下語(yǔ)句3和語(yǔ)句4會(huì)不會(huì)第一個(gè)執(zhí)行?答案是不會(huì)。在進(jìn)行指令重排時(shí)必須要考慮數(shù)據(jù)依賴性。
語(yǔ)句3依賴語(yǔ)句1,語(yǔ)句4依賴語(yǔ)句2,所以語(yǔ)句3和語(yǔ)句4不會(huì)第一個(gè)執(zhí)行。這也告訴我們?nèi)绻Z(yǔ)句之間沒有依賴關(guān)系就可能發(fā)生指令重排。
指令重排在多線程場(chǎng)景下會(huì)產(chǎn)生什么問(wèn)題呢?我們分析一個(gè)多線程指令重排實(shí)例。
public?class?MyTest?{
????int?a?=?0;
????boolean?b?=?false;
????public?void?method1()?{
????????a?=?1000;?//?語(yǔ)句1
????????b?=?true;?//?語(yǔ)句2
????}
????public?void?method2()?{
????????if?(b)?{
????????????a?=?a?+?1;?//?語(yǔ)句3
????????????System.out.println(a);
????????}
????}
????
????public?static?void?main(String[]?args)?{
????????for?(int?i?=?0;?i?10000;?i++)?{
????????????MyTest?test?=?new?MyTest();
????????????new?Thread(()?->?test.method1()).start();
????????????new?Thread(()?->?test.method2()).start();
????????}
????}
}
我們思考一下a最終輸出值是多少?答案是有可能是1或者1001。
-
由于變量a和b不存在數(shù)據(jù)依賴關(guān)系,所以經(jīng)過(guò)指令重排,語(yǔ)句2可能先于語(yǔ)句1執(zhí)行 -
執(zhí)行完語(yǔ)句2后可能還沒有執(zhí)行語(yǔ)句1,method2搶到執(zhí)行機(jī)會(huì)執(zhí)行語(yǔ)句3,這時(shí)執(zhí)行結(jié)果等于1 -
如果指令不重排,執(zhí)行結(jié)果等于1001
所以在多線程環(huán)境,運(yùn)行結(jié)果具有不確定性是指令重排可能帶來(lái)的問(wèn)題。
3 回到問(wèn)題
再回到第一章節(jié)的問(wèn)題:為什么會(huì)出現(xiàn)空指針異常?我們分析這一段代碼。
public?static?MyDCLConnection?getConnection()?{
????if?(null?==?myConnection)?{?//?語(yǔ)句1
????????synchronized?(MyDCLConnection.class)?{
????????????if?(null?==?myConnection)?{
????????????????myConnection?=?new?MyDCLConnection();?//?語(yǔ)句2
????????????}
????????}
????}
????return?myConnection;?//?語(yǔ)句3
}
我們重點(diǎn)分析語(yǔ)句2,new操作在更細(xì)的層面分為以下三個(gè)步驟:
(A)?分配新對(duì)象內(nèi)存
(B)?調(diào)用類構(gòu)造器初始化成員變量
(C)?instance被賦為指向新對(duì)象的引用
經(jīng)過(guò)指令重排可能形成以下新順序:
(A)?分配新對(duì)象內(nèi)存
(B)?instance被賦為指向新對(duì)象的引用
(C)?調(diào)用類構(gòu)造器初始化成員變量
根據(jù)新順序我們分析一種異常場(chǎng)景:
-
線程1執(zhí)行到語(yǔ)句2,執(zhí)行到instance被賦為指向新對(duì)象引用這個(gè)步驟,還沒有進(jìn)行初始化對(duì)象 -
此時(shí)線程2執(zhí)行到語(yǔ)句1,由于instance已經(jīng)被賦為指向新對(duì)象的引用,myConnection已經(jīng)不等于null,所以可以執(zhí)行到語(yǔ)句3 -
但是語(yǔ)句3返回的是沒有進(jìn)行初始化的對(duì)象,所以使用這個(gè)對(duì)象就會(huì)拋出空指針異常
4 Volatile
上述問(wèn)題應(yīng)該如何解決呢?本章節(jié)我們來(lái)談一談Volatile關(guān)鍵字。Volatile是JVM提供的輕量級(jí)同步機(jī)制,具有以下特性:
-
保證可見性 -
不保證原子性 -
保證有序性(禁止指令重排)
其中保證可見性和不保證原子性不在本文進(jìn)行討論,本文我們分析Volatile如何保證有序性。
Volatile禁止指令重排原理是使用了內(nèi)存屏障。內(nèi)存屏障是一種CPU指令,它使CPU或者編譯器對(duì)屏障指令之前和之后發(fā)出的內(nèi)存操作執(zhí)行一個(gè)排序約束。通過(guò)插入內(nèi)存屏障指令,禁止在內(nèi)存屏障指令前后的指令進(jìn)行重排序。內(nèi)存屏障有如下四種類型:
-
LoadLoad -
StoreStore -
LoadStore -
StoreLoad
這樣說(shuō)有一些抽象,我們結(jié)合代碼進(jìn)行分析,還是使用上文代碼實(shí)例,只是不同的是這一次我們新增了Volatile關(guān)鍵字。
public?class?MyTest?{
????int?a?=?0;
????volatile?boolean?b?=?false;
????public?void?method1()?{
????????a?=?1000;?//?語(yǔ)句1
????????b?=?true;?//?語(yǔ)句2
????}
????public?void?method2()?{
????????if?(b)?{
????????????a?=?a?+?1;?//?語(yǔ)句3
????????????System.out.println(a);
????????}
????}
????
????public?static?void?main(String[]?args)?{
????????for?(int?i?=?0;?i?10000;?i++)?{
????????????MyTest?test?=?new?MyTest();
????????????new?Thread(()?->?test.method1()).start();
????????????new?Thread(()?->?test.method2()).start();
????????}
????}
}
我們將b變量聲明為Volatile,那么在為b賦值即Volatile寫前后會(huì)加上如下屏障,從而保證了語(yǔ)句1和語(yǔ)句2執(zhí)行順序不會(huì)重排。
volatile?boolean?b?=?false;
public?void?method1()?{
??a?=?1000;?//?語(yǔ)句1
??StoreStore屏障
??b?=?true;?//?語(yǔ)句2
??StoreLoad屏障
}
在JDK5之后Volatile還可以保證對(duì)象構(gòu)造是有序的,也就是說(shuō)new操作如下步驟可以保證有序,這就為我們解決DCL空指針異常提供了思路。
(A)?分配新對(duì)象內(nèi)存
(B)?調(diào)用類構(gòu)造器初始化成員變量
(C)?instance被賦為指向新對(duì)象的引用
5 解決方案
經(jīng)過(guò)上述分析我們可以使用Volatile解決單例DCL空指針異常。
public?class?MyVolatileConnection?{
????private?static?volatile?MyVolatileConnection?myConnection?=?null;
????private?MyVolatileConnection()?{
????????System.out.println(Thread.currentThread().getName()?+?"?->?init?connection");
????}
????public?static?MyVolatileConnection?getConnection()?{
????????if?(null?==?myConnection)?{
????????????synchronized?(MyVolatileConnection.class)?{
????????????????if?(null?==?myConnection)?{
????????????????????myConnection?=?new?MyVolatileConnection();
????????????????}
????????????}
????????}
????????return?myConnection;
????}
????public?static?void?main(String[]?args)?{
????????for?(int?i?=?0;?i?10;?i++)?{
????????????new?Thread(()?->?{
????????????????MyVolatileConnection.getConnection();
????????????},?"threadName"?+?i).start();
????????}
????}
}
代碼改動(dòng)并不大只需在聲明MyConnection變量處加上Volatile關(guān)鍵字。
本文我們從單例模式的一個(gè)問(wèn)題出發(fā),一步步分析到Volatile關(guān)鍵字原理并最終解決單例模式DCL空指針問(wèn)題,希望本文對(duì)大家有所幫助。
特別推薦一個(gè)分享架構(gòu)+算法的優(yōu)質(zhì)內(nèi)容,還沒關(guān)注的小伙伴,可以長(zhǎng)按關(guān)注一下:
長(zhǎng)按訂閱更多精彩▼
如有收獲,點(diǎn)個(gè)在看,誠(chéng)摯感謝
免責(zé)聲明:本文內(nèi)容由21ic獲得授權(quán)后發(fā)布,版權(quán)歸原作者所有,本平臺(tái)僅提供信息存儲(chǔ)服務(wù)。文章僅代表作者個(gè)人觀點(diǎn),不代表本平臺(tái)立場(chǎng),如有問(wèn)題,請(qǐng)聯(lián)系我們,謝謝!