【最近面試遇到的一些問題】線程安全-單例模式[轉]

單例的目的是為了保證運作時singleton類隻有唯一的一個執行個體，最常用的地方比如拿到資料庫的連接配接，spring的中建立beanfactory這些開銷比較大的操作，而這些操作都是調用他們的方法來執行某個特定的動作。

面試官的問題是：單例會帶來什麼問題？

我第一反映就是如果多個線程同時調用這個執行個體，會有線程安全的問題，當時就這麼說了，然後他問：“怎麼實作一個線程安全的單例模式呢？”

這個問題我沒有回答上來，當時腦子裡閃了一下如果用synchronized來鎖定可能會有一些問題，至于是什麼問題沒有想明白，就選擇沒有回答。

實際上使用什麼樣的單例實作取決于不同的生産環境，懶漢式也就是我在上面舉得那個例子，這種方式适合于單線程程式，多線程情況下需要保護getinstance()方法，否則可能會産生多個singleton對象的執行個體。

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

但很多時候我們通常會認為鎖定整個方法的是比較耗費資源的，代碼中實際會産生多線程通路問題的隻有

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 static synchronized singleton getinstance(){ 

/* 安全的方式 2 */

public class singleton {

  private static singleton instance = new singleton();

  private singleton() {}

  public static singleton getinstance() {

  }

}

這種方式沒有使用同步，并且確定了調用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 {   

這裡隐含了一個是static關鍵字的用法，使用static關鍵字修飾的變量隻有在第一次使用的時候才會被初始化，而且一個類裡面static的成員變量隻會有一份，這樣就保證了無論多少個線程同時通路，所拿到的resource對象都是同一個。

餓漢式的實作方式雖然貌似開銷比較大，但是不會出現線程安全的問題，也是解決線程安全的單例實作的有效方式。

至于threadlocal，我認為還是應該由使用場景來決定。

在《java與模式》中，作者提出：“餓漢式單例類可以在java語言實作，但不易在c++内實作，因為靜态初始化在c++裡沒有固定的順序，因而靜态的instance變量的初始化與類的加載順序沒有保證，可能會出問題。這就是為什麼gof在提出單例類的概念時，舉的例子是懶漢式的。他們的書影響之大，以緻java語言中單例類的例子也大多是懶漢式的。實際上，本書認為餓漢式單例類更符合java語言本身的特點。”

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