Java單例模式詳解

...wd......wd......wd...深入Java單例模式2009-09-2010:57:12標(biāo)簽：Java原創(chuàng)作品，允許轉(zhuǎn)載，轉(zhuǎn)載時請務(wù)必以超鏈接形式標(biāo)明文章原始出處、作者信息和本聲明。否則將追究法律責(zé)任。://devbean.blog.51cto/448512/203501在GoF的23種設(shè)計模式中，單例模式是比較簡單的一種。然而，有時候越是簡單的東西越容易出現(xiàn)問題。下面就單例設(shè)計模式詳細(xì)的探討一下。所謂單例模式，簡單來說，就是在整個應(yīng)用中保證只有一個類的實例存在。就像是JavaWeb中的application，也就是提供了一個全局變量，用處相當(dāng)廣泛，比方保存全局?jǐn)?shù)據(jù)，實現(xiàn)全局性的操作等。1.最簡單的實現(xiàn)首先，能夠想到的最簡單的實現(xiàn)是，把類的構(gòu)造函數(shù)寫成private的，從而保證別的類不能實例化此類，然后在類中提供一個靜態(tài)的實例并能夠返回給使用者。這樣，使用者就可以通過這個引用使用到這個類的實例了。publicclassSingletonClass{

privatestaticfinalSingletonClassinstance=newSingletonClass();

publicstaticSingletonClassgetInstance(){

returninstance;

}

privateSingletonClass(){

}

}如上例，外部使用者如果需要使用SingletonClass的實例，只能通過getInstance()方法，并且它的構(gòu)造方法是private的，這樣就保證了只能有一個對象存在。2.性能優(yōu)化——lazyloaded上面的代碼雖然簡單，但是有一個問題——無論這個類是否被使用，都會創(chuàng)立一個instance對象。如果這個創(chuàng)立過程很耗時，比方需要連接10000次數(shù)據(jù)庫(夸張了…:-))，并且這個類還并不一定會被使用，那么這個創(chuàng)立過程就是無用的。怎么辦呢為了解決這個問題，我們想到了新的解決方案：publicclassSingletonClass{

privatestaticSingletonClassinstance=null;

publicstaticSingletonClassgetInstance(){

if(instance==null){

instance=newSingletonClass();

}

returninstance;

}

privateSingletonClass(){

}

}代碼的變化有兩處——首先，把instance初始化為null，直到第一次使用的時候通過判斷是否為null來創(chuàng)立對象。因為創(chuàng)立過程不在聲明處，所以那個final的修飾必須去掉。我們來想象一下這個過程。要使用SingletonClass，調(diào)用getInstance()方法。第一次的時候發(fā)現(xiàn)instance是null，然后就新建一個對象，返回出去；第二次再使用的時候，因為這個instance是static的，所以已經(jīng)不是null了，因此不會再創(chuàng)立對象，直接將其返回。這個過程就成為lazyloaded，也就是遲加載——直到使用的時候才進展加載。3.同步上面的代碼很清楚，也很簡單。然而就像那句名言：“80%的錯誤都是由20%代碼優(yōu)化引起的〞。單線程下，這段代碼沒有什么問題，可是如果是多線程，麻煩就來了。我們來分析一下：線程A希望使用SingletonClass，調(diào)用getInstance()方法。因為是第一次調(diào)用，A就發(fā)現(xiàn)instance是null的，于是它開場創(chuàng)立實例，就在這個時候，CPU發(fā)生時間片切換，線程B開場執(zhí)行，它要使用SingletonClass，調(diào)用getInstance()方法，同樣檢測到instance是null——注意，這是在A檢測完之后切換的，也就是說A并沒有來得及創(chuàng)立對象——因此B開場創(chuàng)立。B創(chuàng)立完成后，切換到A繼續(xù)執(zhí)行，因為它已經(jīng)檢測完了，所以A不會再檢測一遍，它會直接創(chuàng)立對象。這樣，線程A和B各自擁有一個SingletonClass的對象——單例失敗！解決的方法也很簡單，那就是加鎖：publicclassSingletonClass{

privatestaticSingletonClassinstance=null;

publicsynchronizedstaticSingletonClassgetInstance(){

if(instance==null){

instance=newSingletonClass();

}

returninstance;

}

privateSingletonClass(){

}

}是要getInstance()加上同步鎖，一個線程必須等待另外一個線程創(chuàng)立完成后才能使用這個方法，這就保證了單例的唯一性。4.又是性能上面的代碼又是很清楚很簡單的，然而，簡單的東西往往不夠理想。這段代碼毫無疑問存在性能的問題——synchronized修飾的同步塊可是要比一般的代碼段慢上幾倍的！如果存在很屢次getInstance()的調(diào)用，那性能問題就不得不考慮了！讓我們來分析一下，終究是整個方法都必須加鎖，還是僅僅其中某一句加鎖就足夠了我們?yōu)槭裁匆渔i呢分析一下出現(xiàn)lazyloaded的那種情形的原因。原因就是檢測null的操作和創(chuàng)立對象的操作別離了。如果這兩個操作能夠原子地進展，那么單例就已經(jīng)保證了。于是，我們開場修改代碼：publicclassSingletonClass{

privatestaticSingletonClassinstance=null;

publicstaticSingletonClassgetInstance(){

synchronized(SingletonClass.class){

if(instance==null){

instance=newSingletonClass();

}

}

returninstance;

}

privateSingletonClass(){

}

}首先去掉getInstance()的同步操作，然后把同步鎖加載if語句上。但是這樣的修改起不到任何作用：因為每次調(diào)用getInstance()的時候必然要同步，性能問題還是存在。如果……如果我們事先判斷一下是不是為null再去同步呢publicclassSingletonClass{

privatestaticSingletonClassinstance=null;

publicstaticSingletonClassgetInstance(){

if(instance==null){

synchronized(SingletonClass.class){

if(instance==null){

instance=newSingletonClass();

}

}

}

returninstance;

}

privateSingletonClass(){

}

}還有問題嗎首先判斷instance是不是為null，如果為null，加鎖初始化；如果不為null，直接返回instance。這就是double-checkedlocking設(shè)計實現(xiàn)單例模式。到此為止，一切都很完美。我們用一種很聰明的方式實現(xiàn)了單例模式。5.從源頭檢查下面我們開場說編譯原理。所謂編譯，就是把源代碼“翻譯〞成目標(biāo)代碼——大多數(shù)是指機器代碼——的過程。針對Java，它的目標(biāo)代碼不是本地機器代碼，而是虛擬機代碼。編譯原理里面有一個很重要的內(nèi)容是編譯器優(yōu)化。所謂編譯器優(yōu)化是指，在不改變原來語義的情況下，通過調(diào)整語句順序，來讓程序運行的更快。這個過程成為reorder。要知道，JVM只是一個標(biāo)準(zhǔn)，并不是實現(xiàn)。JVM中并沒有規(guī)定有關(guān)編譯器優(yōu)化的內(nèi)容，也就是說，JVM實現(xiàn)可以自由的進展編譯器優(yōu)化。下面來想一下，創(chuàng)立一個變量需要哪些步驟呢一個是申請一塊內(nèi)存，調(diào)用構(gòu)造方法進展初始化操作，另一個是分配一個指針指向這塊內(nèi)存。這兩個操作誰在前誰在后呢JVM標(biāo)準(zhǔn)并沒有規(guī)定。那么就存在這么一種情況，JVM是先開辟出一塊內(nèi)存，然后把指針指向這塊內(nèi)存，最后調(diào)用構(gòu)造方法進展初始化。下面我們來考慮這么一種情況：線程A開場創(chuàng)立SingletonClass的實例，此時線程B調(diào)用了getInstance()方法，首先判斷instance是否為null。按照我們上面所說的內(nèi)存模型，A已經(jīng)把instance指向了那塊內(nèi)存，只是還沒有調(diào)用構(gòu)造方法，因此B檢測到instance不為null，于是直接把instance返回了——問題出現(xiàn)了，盡管instance不為null，但它并沒有構(gòu)造完成，就像一套房子已經(jīng)給了你鑰匙，但你并不能住進去，因為里面還沒有收拾。此時，如果B在A將instance構(gòu)造完成之前就是用了這個實例，程序就會出現(xiàn)錯誤了！于是，我們想到了下面的代碼：publicclassSingletonClass{

privatestaticSingletonClassinstance=null;

publicstaticSingletonClassgetInstance(){

if(instance==null){

SingletonClasssc;

synchronized(SingletonClass.class){

sc=instance;

if(sc==null){

synchronized(SingletonClass.class){

if(sc==null){

sc=newSingletonClass();

}

}

instance=sc;

}

}

}

returninstance;

}

privateSingletonClass(){

}

}我們在第一個同步塊里面創(chuàng)立一個臨時變量，然后使用這個臨時變量進展對象的創(chuàng)立，并且在最后把instance指針臨時變量的內(nèi)存空間。寫出這種代碼基于以下思想，即synchronized會起到一個代碼屏蔽的作用，同步塊里面的代碼和外部的代碼沒有聯(lián)系。因此，在外部的同步塊里面對臨時變量sc進展操作并不影響instance，所以外部類在instance=sc;之前檢測instance的時候，結(jié)果instance依然是null。不過，這種想法完全是錯誤的！同步塊的釋放保證在此之前——也就是同步塊里面——的操作必須完成，但是并不保證同步塊之后的操作不能因編譯器優(yōu)化而調(diào)換到同步塊完畢之前進展。因此，編譯器完全可以把instance=sc;這句移到內(nèi)部同步塊里面執(zhí)行。這樣，程序又是錯誤的了！6.解決方案說了這么多，難道單例沒有方法在Java中實現(xiàn)嗎其實不然！在JDK5之后，Java使用了新的內(nèi)存模型。volatile關(guān)鍵字有了明確的語義——在JDK1.5之前，volatile是個關(guān)鍵字，但是并沒有明確的規(guī)定其用途——被volatile修飾的寫變量不能和之前的讀寫代碼調(diào)整，讀變量不能和之后的讀寫代碼調(diào)整！因此，只要我們簡單的把instance加上volatile關(guān)鍵字就可以了。publicclassSingletonClass{

privatevolatilestaticSingletonClassinstance=null;

publicstaticSingletonClassgetInstance(){

if(instance==null){

synchronized(SingletonClass.class){

if(instance==null){

instance=newSingletonClass();

}

}

}

returninstance;

}

privateSingletonClass(){

}

}然而，這只是JDK1.5之后的Java的解決方案，那之前版本呢其實，還有另外的一種解決方案，并不會受到Java版本的影響：publicclassSingletonClass{

privatestaticclassSingletonClassInstance{

privatestaticfinalSingletonClassinstance=newSingletonClass();

}

publicstaticSingletonClassgetInstance