單例模式的七種寫法, 面試題:執行緒安全的單例模式
http://cantellow.iteye.com/blog/838473
http://meizhi.iteye.com/blog/537563
第一種(懶漢,執行緒不安全):
Java程式碼- public class Singleton {
- private static Singleton instance;
- private Singleton (){}
- public static Singleton getInstance() {
- if (instance == null) {
- instance = new Singleton();
- }
- return instance;
- }
- }
這種寫法lazy loading很明顯,但是致命的是在多執行緒不能正常工作。
第二種(懶漢,執行緒安全):
Java程式碼- public class Singleton {
- private static Singleton instance;
- private Singleton (){}
- public static synchronized Singleton getInstance() {
- if (instance == null) {
- instance = new
- }
- return instance;
- }
- }
這種寫法能夠在多執行緒中很好的工作,而且看起來它也具備很好的lazy loading,但是,遺憾的是,效率很低,99%情況下不需要同步。
第三種(餓漢):
Java程式碼- public class Singleton {
- private static Singleton instance = new Singleton();
- private Singleton (){}
- public static Singleton getInstance() {
- return instance;
- }
- }
這種方式基於classloder機制避免了多執行緒的同步問題,不過,instance在類裝載時就例項化,雖然導致類裝載的原因有很多種,在單例模式中大多數都是呼叫getInstance方法, 但是也不能確定有其他的方式(或者其他的靜態方法)導致類裝載,這時候初始化instance顯然沒有達到lazy loading的效果。
第四種(餓漢,變種):
Java程式碼- public class Singleton {
- private Singleton instance = null;
- static {
- instance = new Singleton();
- }
- private Singleton (){}
- public static Singleton getInstance() {
- return this.instance;
- }
- }
表面上看起來差別挺大,其實更第三種方式差不多,都是在類初始化即例項化instance。
第五種(靜態內部類):
Java程式碼- public class Singleton {
- private static class SingletonHolder {
- private static final Singleton INSTANCE = new Singleton();
- }
- private Singleton (){}
- public static final Singleton getInstance() {
- return SingletonHolder.INSTANCE;
- }
- }
這種方式同樣利用了classloder的機制來保證初始化instance時只有一個執行緒,它跟第三種和第四種方式不同的是(很細微的差別):第三種和第四種方式是隻要Singleton類被裝載了,那麼instance就會被例項化(沒有達到lazy loading效果),而這種方式是Singleton類被裝載了,instance不一定被初始化。因為SingletonHolder類沒有被主動使用,只有顯示通過呼叫getInstance方法時,才會顯示裝載SingletonHolder類,從而例項化instance。想象一下,如果例項化instance很消耗資源,我想讓他延遲載入,另外一方面,我不希望在Singleton類載入時就例項化,因為我不能確保Singleton類還可能在其他的地方被主動使用從而被載入,那麼這個時候例項化instance顯然是不合適的。這個時候,這種方式相比第三和第四種方式就顯得很合理。
第六種(列舉):
Java程式碼- public enum Singleton {
- INSTANCE;
- public void whateverMethod() {
- }
- }
這種方式是Effective Java作者Josh Bloch 提倡的方式,它不僅能避免多執行緒同步問題,而且還能防止反序列化重新建立新的物件,可謂是很堅強的壁壘啊,不過,個人認為由於1.5中才加入enum特性,用這種方式寫不免讓人感覺生疏,在實際工作中,我也很少看見有人這麼寫過。
第七種(雙重校驗鎖):
Java程式碼- public class Singleton {
- private volatile static Singleton singleton;
- private Singleton (){}
- public static Singleton getSingleton() {
- if (singleton == null) {
- synchronized (Singleton.class) {
- if (singleton == null) {
- singleton = new Singleton();
- }
- }
- }
- return singleton;
- }
- }
在JDK1.5之後,雙重檢查鎖定才能夠正常達到單例效果。
總結
有兩個問題需要注意:
1.如果單例由不同的類裝載器裝入,那便有可能存在多個單例類的例項。假定不是遠端存取,例如一些servlet容器對每個servlet使用完全不同的類裝載器,這樣的話如果有兩個servlet訪問一個單例類,它們就都會有各自的例項。
2.如果Singleton實現了java.io.Serializable介面,那麼這個類的例項就可能被序列化和復原。不管怎樣,如果你序列化一個單例類的物件,接下來複原多個那個物件,那你就會有多個單例類的例項。
對第一個問題修復的辦法是:
Java程式碼- private static Class getClass(String classname)
- throws ClassNotFoundException {
- ClassLoader classLoader = Thread.currentThread().getContextClassLoader();
- if(classLoader == null)
- classLoader = Singleton.class.getClassLoader();
- return (classLoader.loadClass(classname));
- }
- }
對第二個問題修復的辦法是:
Java程式碼- public class Singleton implements java.io.Serializable {
- public static Singleton INSTANCE = new Singleton();
- protected Singleton() {
- }
- private Object readResolve() {
- return INSTANCE;
- }
- }
對我來說,我比較喜歡第三種和第五種方式,簡單易懂,而且在JVM層實現了執行緒安全(如果不是多個類載入器環境),一般的情況下,我會使用第三種方式,只有在要明確實現lazy loading效果時才會使用第五種方式,另外,如果涉及到反序列化建立物件時我會試著使用列舉的方式來實現單例,不過,我一直會保證我的程式是執行緒安全的,而且我永遠不會使用第一種和第二種方式,如果有其他特殊的需求,我可能會使用第七種方式,畢竟,JDK1.5已經沒有雙重檢查鎖定的問題了。
========================================================================
不過一般來說,第一種不算單例,第四種和第三種就是一種,如果算的話,第五種也可以分開寫了。所以說,一般單例都是五種寫法。懶漢,惡漢,雙重校驗鎖,列舉和靜態內部類。
我很高興有這樣的讀者,一起共勉
=======================================================================
面試被問到一個執行緒安全的單例模式問題,想拿出來討論一下,
我通常會使用的這樣的寫法來實現單例:
- public class Singleton {
- private Singleton() {}
- private static Singleton instance = null;
- public static Singleton getInstance() {
- if(instance == null) {
- instance = new Singleton();
- }
- return instance;
- }
- }
單例的目的是為了保證執行時Singleton類只有唯一的一個例項,最常用的地方比如拿到資料庫的連線,spring的中建立BeanFactory這些開銷比較大的操作,而這些操作都是呼叫他們的方法來執行某個特定的動作。
面試官的問題是:單例會帶來什麼問題?
我第一反映就是如果多個執行緒同時呼叫這個例項,會有執行緒安全的問題,當時就這麼說了,然後他問:“怎麼實現一個執行緒安全的單例模式呢?”
這個問題我沒有回答上來,當時腦子裡閃了一下如果用synchronized來鎖定可能會有一些問題,至於是什麼問題沒有想明白,就選擇沒有回答。
這裡請問各位高手,
1、如果不執行修改物件的操作的情況下,單單執行一個讀取操作,還有沒有進行同步的必要?
2、保證單例的執行緒安全使用synchronized會產生什麼樣的問題?
3、不使用synchronized,有什麼方式來保證執行緒安全?
4、假如下次再面試遇到這種情形,用什麼方式回答會使面試官感到比較滿意?
--------------------------------------------------------------------------------------------------------------------------------------------------------------
感謝大家的討論與支援,總結一下:
實際上使用什麼樣的單例實現取決於不同的生產環境,懶漢式也就是我在上面舉得那個例子,這種方式適合於單執行緒程式,多執行緒情況下需要保護getInstance()方法,否則可能會產生多個Singleton物件的例項。
在此基礎上確保getInstance()方法一次只能被一個執行緒呼叫就需要在getInstance()方法之前加上 synchronized 關鍵字,鎖定整個方法,
Java程式碼- public class Singleton{
- private static Singleton instance=null;
- private Singleton(){}
- public static synchronized Singleton getInstance(){
- if(instance==null){
- instance=new Singleton();
- }
- return instance;
- }
- }
但很多時候我們通常會認為鎖定整個方法的是比較耗費資源的,程式碼中實際會產生多執行緒訪問問題的只有 instance = new Singleton(); 這一句,
為了降低 synchronized 塊效能方面的影響,只鎖定instance = new Singleton(); 這一句,“weishuang”回帖中使用的就是這種方式:
Java程式碼- public class Singleton{
- private static Singleton instance=null;
- private Singleton(){}
- public static Singleton getInstance(){
- if(instance==null){
- synchronized(Singleton.class){
- instance=new Singleton();
- }
- }
- return instance;
- }
- }
分析這種實現方式,兩個執行緒可以併發地進入第一次判斷instance是否為空的if 語句內部,第一個執行緒執行new操作,第二個執行緒阻斷,當第一個執行緒執行完畢之後,第二個執行緒沒有進行判斷就直接進行new操作,所以這樣做也並不是安全的。
為了避免第二次進入synchronized塊沒有進行非空判斷的情況發生,新增第二次條件判斷,就像“tomorrow009”在帖子中回覆的示例一樣
Java程式碼- public static Singleton getInstance(){
- if(instance == null){
- synchronize{
- if(instance == null){
- instance = new Singleton();
- }
- }
- }
- return instance;
- }
這樣就產生了二次檢查,但是二次檢查自身會存在比較隱蔽的問題,查了Peter Haggar在DeveloperWorks上的一篇文章,對二次檢查的解釋非常的詳細:
其實找到這篇文章之後,我的問題基本上就已經可以解決了,但是看到回帖的同學們也有一些和我一樣的問題,還想把這個問題繼續梳理一遍。
使用二次檢查的方法也不是完全安全的,原因是 Java 平臺記憶體模型中允許所謂的“無序寫入”會導致二次檢查失敗,所以使用二次檢查的想法也行不通了。
Peter Haggar在最後提出這樣的觀點:“無論以何種形式,都不應使用雙重檢查鎖定,因為您不能保證它在任何 JVM 實現上都能順利執行。”
"netrice"在回覆中提到了使用“java5以後的volatile關鍵字”,用volatile關鍵字來宣告變數,宣告成 volatile 的變數被認為是順序一致的,即,不是重新排序的。但是volatile關鍵字的特性並不適用於這篇帖子所討論的問題關鍵。
通過上面的分析,可以看到使用懶漢式的lazy方式實現單例彎彎繞太多,在單執行緒程式設計的情況下懶漢式單例實現是沒有任何問題的,如果在多執行緒的情況下,我們需要比較小心,對getInstances()方法加上synchronized關鍵字,這樣雖然可能有一些效能上的犧牲,但是更加的安全。繞了這麼大的一個彎,又回來了:
Java程式碼- /* 安全的方式 1 */
- public class Singleton{
- private static Singleton instance=null;
- private Singleton(){}
- public static synchronized Singleton getInstance(){
- if(instance==null){
- instance=new Singleton();
- }
- return instance;
- }
- }
Peter Haggar提到的另外一種實現方式是這樣的,放棄使用 synchronized 關鍵字,而使用 static 關鍵字:
Java程式碼- /* 安全的方式 2 */
- public class Singleton {
- private static Singleton instance = new Singleton();
- private Singleton() {}
- public static Singleton getInstance() {
- return instance;
- }
- }
這種方式沒有使用同步,並且確保了呼叫static getInstance()方法時才建立Singleton的引用(static 的成員變數在一個類中只有一份)。
還有“keshin”提到的方式則更加靈巧,沒有使用同步但保證了只有一個例項,還同時具有了Lazy的特性(出自Lazy Loading Singletons)
Java程式碼- /* 安全的方式 3 */
- public class ResourceFactory {
- private static class ResourceHolder {
- public static Resource resource = new Resource();
- }
- public static Resource getResource() {
- return ResourceFactory.ResourceHolder.resource;
- }
- static class Resource {
- }
- }
上面的方式是值得借鑑的,在ResourceFactory中加入了一個私有靜態內部類ResourceHolder ,對外提供的介面是 getResource()方法,也就是隻有在ResourceFactory .getResource()的時候,Resource物件才會被建立,
這種寫法的巧妙之處在於ResourceFactory 在使用的時候ResourceHolder 會被初始化,但是ResourceHolder 裡面的resource並沒有被建立,
這裡隱含了一個是static關鍵字的用法,使用static關鍵字修飾的變數只有在第一次使用的時候才會被初始化,而且一個類裡面static的成員變數只會有一份,這樣就保證了無論多少個執行緒同時訪問,所拿到的Resource物件都是同一個。
餓漢式的實現方式雖然貌似開銷比較大,但是不會出現執行緒安全的問題,也是解決執行緒安全的單例實現的有效方式。
至於ThreadLocal,我認為還是應該由使用場景來決定。
在《Java與模式》中,作者提出:“餓漢式單例類可以在Java語言實現,但不易在C++內實現,因為靜態初始化在C++裡沒有固定的順序,因而靜態的instance變數的初始化與類的載入順序沒有保證,可能會出問題。這就是為什麼GoF在提出單例類的概念時,舉的例子是懶漢式的。他們的書影響之大,以致Java語言中單例類的例子也大多是懶漢式的。實際上,本書認為餓漢式單例類更符合Java語言本身的特點。”
由此可見在應用設計模式的同時,分析具體的使用場景來選擇合適的實現方式是非常必要的。
尋找問題解決過程中找的一些參考資料:
因為在精華帖中沒有找到很流暢解釋這個問題的內容才發了這個帖子,還是很不幸的被評為了新手帖,但如果下次有面試官問有關執行緒安全的單例模式問題,我想我知道該怎麼回答了