線程安全的單例模式

通常會使用的這樣的寫法來實現單例：

    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這些開銷比較大的操作，而這些操作都是調用他們的方法來執行某個特定的動作。

實際上使用什麼樣的單例實現取決於不同的生產環境，懶漢式也就是我在上面舉得那個例子，這種方式適合於單線程程序，多線程情況下需要保護getInstance()方法，否則可能會產生多個Singleton對象的實例。

在此基礎上確保getInstance()方法一次只能被一個線程調用就需要在getInstance()方法之前加上 synchronized 關鍵字，鎖定整個方法，

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”回帖中使用的就是這種方式：

    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”在帖子中回覆的示例一樣

 

public static Singleton getInstance(){     
    if(instance == null){     
        synchronize{     
           if(instance == null){     
              instance =  new Singleton();      
           }     
        }     
    }     
    return instance;  
}  

這樣就產生了二次檢查，但是二次檢查自身會存在比較隱蔽的問題，查了Peter Haggar在DeveloperWorks上的一篇文章，對二次檢查的解釋非常的詳細：

“雙重檢查鎖定背後的理論是完美的。不幸地是，現實完全不同。雙重檢查鎖定的問題是：並不能保證它會在單處理器或多處理器計算機上順利運行。雙重檢查鎖定失敗的問題並不歸咎於 JVM 中的實現 bug，而是歸咎於 Java 平臺內存模型。內存模型允許所謂的“無序寫入”，這也是這些習語失敗的一個主要原因。”

 

其實找到這篇文章之後，我的問題基本上就已經可以解決了，但是看到回帖的同學們也有一些和我一樣的問題，還想把這個問題繼續梳理一遍。

 

使用二次檢查的方法也不是完全安全的，原因是 java 平臺內存模型中允許所謂的“無序寫入”會導致二次檢查失敗，所以使用二次檢查的想法也行不通了。

 

Peter Haggar在最後提出這樣的觀點：“無論以何種形式，都不應使用雙重檢查鎖定，因爲您不能保證它在任何 JVM 實現上都能順利運行。”

 

"netrice"在回覆中提到了使用“java5以後的volatile關鍵字”，用volatile關鍵字來聲明變量，聲明成 volatile 的變量被認爲是順序一致的，即，不是重新排序的。但是volatile關鍵字的特性並不適用於這篇帖子所討論的問題關鍵。

 

通過上面的分析，可以看到使用懶漢式的lazy方式實現單例彎彎繞太多，在單線程編程的情況下懶漢式單例實現是沒有任何問題的，如果在多線程的情況下，我們需要比較小心，對getInstances()方法加上synchronized關鍵字，這樣雖然可能有一些性能上的犧牲，但是更加的安全。繞了這麼大的一個彎，又回來了：

    /* 安全的方式 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 關鍵字：

    /* 安全的方式 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）

    /* 安全的方式 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語言本身的特點。”

 

由此可見在應用設計模式的同時，分析具體的使用場景來選擇合適的實現方式是非常必要的。