設計模式梳理單例模式

一概念介紹：

所謂單例模式，簡單來說，就是在整個應用中保證只有乙個類的例項存在，而且自行例項化並向整個系統提供這個例項。單例物件通常作為程式中的存放配置資訊的載體，因為它能保證其他物件讀到一致的資訊。例如在某個伺服器程式中，該伺服器的配置資訊可能存放在資料庫或檔案中，這些配置資料由某個單例物件統一讀取，服務程序中的其他物件如果要獲取這些配置資訊，只需訪問該單例物件即可。這種方式極大地簡化了在複雜環境下，尤其是多執行緒環境下的配置管理，但是隨著應用場景的不同，也可能帶來一些同步問題。

幾種寫法：

第一種（懶漢，執行緒不安全）：

public class singleton 	
public static singleton getinstace()
return instace;}}

這是最簡單的實現，把類的建構函式寫成private的，從而保證別的類不能例項化此類，然後在類中提供乙個靜態的例項並能夠返回給使用者。這樣，使用者就可以通過這個引用使用到這個類的例項了。

缺點：這種寫法lazy loading很明顯，但是致命的是在多執行緒不能正常工作。

第二種（懶漢，執行緒安全）：

public class singleton 	
public static synchronized singleton getinstace()
return instace;}}

解決的方法也很簡單，那就是加鎖，乙個執行緒必須等待另外乙個執行緒建立完成後才能使用這個方法，這就保證了單例的唯一性。

缺點：效率很低，多數情況下不需要同步。

第三種（餓漢）：

public class singleton 
public static singleton getinstance() 
}

或者

public class singleton 
private singleton(){} 
public static singleton getinstace()
}

優缺點：

這種方式基於

classloder

機制避免了多執行緒的同步問題，不過，

instance

在類裝載時就例項化，雖然導致類裝載的原因有很多種，在單例模式中大多數都是呼叫

getinstance

方法，但是也不能確定有其他的方式（或者其他的靜態方法）導致類裝載，這時候初始化

instance

顯然沒有達到

lazy loading

的效果。

第四種（靜態內部類）：

public class singleton 
private singleton(){} 
public static final singleton getinstace()
}

這種方式同樣利用了

classloder

的機制來保證初始化

instance

時只有乙個執行緒，它跟第三種比區別如下：

第三種：

只要singleton類被裝載了，那麼instance就會被例項化（沒有達到lazy loading效果）。

第四種：singleton類被裝載了，instance不一定被初始化，因為：singletonclass沒有static的屬性，類沒有被主動使用，並不會被初始化。直到呼叫getinstance()的時候，會首先載入singletonclassinstance類，這個類有乙個static的singletonclass例項，因此需要呼叫singletonclass的構造方法，然後getinstance()將把這個內部類的instance返回給使用者。由於這個instance是static的，因此並不會構造多次。

場景：如果例項化

instance

很消耗資源，我想讓他延遲載入，另外一方面，我不希望在

singleton

類載入時就例項化。就比第三種合適了。

第五種（雙重校驗鎖）：

對於第二種加鎖方

式的優化。第二種是整個方法都必須加鎖，為了優化效能，把檢測null的操作和建立物件的操作分離。

public class singleton 	
public static singleton getinstace()}}
return instance;}}

關於

volatile ，是因為如下原因：

建立乙個變數需要哪些步驟呢？乙個是申請一塊記憶體，呼叫構造方法進行初始化操作，另乙個是分配乙個指標指向這塊記憶體。jvm並沒有規定順序，這兩個操作因為編譯器優化可能呼叫構造方法被放在後面。所以用volatile來保證執行順序。

************總結*******************

實際還是推薦第四種，靜態內部類來實現單例模式。也跟我們之前筆記梳理的static串起來了。

相關知識有延遲載入、鎖同步及優化，靜態內部類等。

當然設計模式的23種很多，我還在學習中，要做到活學活用還要不斷嘗試，不被規則束縛。

參考：

設計模式梳理單例模式

單例模式梳理

設計模式單例模式

設計模式單例模式

設計模式梳理 單例模式

單例模式 梳理

設計模式 單例模式

設計模式 單例模式

相關推薦

設計模式梳理單例模式

單例模式梳理

設計模式單例模式

設計模式單例模式