==！因為最近面試的問題，老是被問到了設計模式，其中單例也是用的最多的，但是之前由於自己之前寫的時候腦子抽抽的，沒想那些什麼執行緒安全不安全，序列化時會導致單例失效什麼的，然後今晚沒事做整理了下相關知識點，方便以後查閱

1.定義

作為物件的建立模式，單例模式確保某一個類只有一個例項，而且自行例項化並向整個系統提供這個例項。這個類稱為單例類。

2.特點

單例類只能有一個例項。

單例類必須自己建立自己的唯一例項。

單例類必須給所有其他物件提供這一例項。

二、建立單例模式的方式

①懶漢式，執行緒不安全

懶漢式其實是一種比較形象的稱謂。既然懶，那麼在建立物件例項的時候就不著急。會一直等到馬上要使用物件例項的時候才會建立，懶人嘛，總是推脫不開的時候才會真正去執行工作，因此在裝載物件的時候不建立物件例項。

public class Singleton {
    private static Singleton instance;
    private Singleton (){}

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

這段程式碼簡單明瞭，而且使用了懶載入模式，但是卻存在致命的問題。當有多個執行緒並行呼叫 getInstance() 的時候，就會建立多個例項。也就是說在多執行緒下不能正常工作。

②懶漢式，執行緒安全

為了解決上面的問題，最簡單的方法是將整個 getInstance() 方法設為同步（synchronized）。

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

雖然做到了執行緒安全，並且解決了多例項的問題，但是它並不高效。因為在任何時候只能有一個執行緒呼叫 getInstance() 方法。但是同步操作只需要在第一次呼叫時才被需要，即第一次建立單例例項物件時。這就引出了雙重檢驗鎖。

③雙重檢驗鎖

雙重檢驗鎖模式（double checked locking pattern），是一種使用同步塊加鎖的方法。程式設計師稱其為雙重檢查鎖，因為會有兩次檢查 instance == null，一次是在同步塊外，一次是在同步塊內。為什麼在同步塊內還要再檢驗一次？因為可能會有多個執行緒一起進入同步塊外的 if，如果在同步塊內不進行二次檢驗的話就會生成多個例項了。

public static Singleton getSingleton() {
    if (instance == null) {                         //Single Checked
        synchronized (Singleton.class) {
            if (instance == null) {                 //Double Checked
                instance = new Singleton();
            }
        }
    }
    return instance ;
}

這段程式碼看起來很完美，很可惜，它是有問題。主要在於instance = new Singleton()這句，這並非是一個原子操作，事實上在 JVM 中這句話大概做了下面 3 件事情:

1.給 instance 分配記憶體

2.呼叫 Singleton 的建構函式來初始化成員變數

3.將instance物件指向分配的記憶體空間（執行完這步 instance 就為非 null 了）。

但是在 JVM 的即時編譯器中存在指令重排序的優化。也就是說上面的第二步和第三步的順序是不能保證的，最終的執行順序可能是 1-2-3 也可能是 1-3-2。如果是後者，則在 3 執行完畢、2 未執行之前，被執行緒二搶佔了，這時 instance 已經是非 null 了（但卻沒有初始化），所以執行緒二會直接返回 instance，然後使用，然後順理成章地報錯。

我們只需要將 instance 變數宣告成 volatile 就可以了。

public class Singleton {
    private volatile static Singleton instance; //宣告成 volatile
    private Singleton (){}

    public static Singleton getSingleton() {
        if (instance == null) {                         
            synchronized (Singleton.class) {
                if (instance == null) {       
                    instance = new Singleton();
                }
            }
        }
        return instance;
    }

}

有些人認為使用 volatile 的原因是可見性，也就是可以保證執行緒在本地不會存有 instance 的副本，每次都是去主記憶體中讀取。但其實是不對的。**使用 volatile 的主要原因是其另一個特性：禁止指令重排序優化。**也就是說，在 volatile 變數的賦值操作後面會有一個記憶體屏障（生成的彙編程式碼上），讀操作不會被重排序到記憶體屏障之前。比如上面的例子，取操作必須在執行完 1-2-3 之後或者 1-3-2 之後，不存在執行到 1-3 然後取到值的情況。

從「先行發生原則」的角度理解的話，就是對於一個 volatile 變數的寫操作都先行發生於後面對這個變數的讀操作（這裡的“後面”是時間上的先後順序）。

但是特別注意在 Java 5 以前的版本使用了 volatile 的雙檢鎖還是有問題的。其原因是 Java 5 以前的 JMM （Java 記憶體模型）是存在缺陷的，即時將變數宣告成 volatile 也不能完全避免重排序，主要是 volatile 變數前後的程式碼仍然存在重排序問題。這個 volatile 遮蔽重排序的問題在 Java 5 中才得以修復，所以在這之後才可以放心使用 volatile。

相信你不會喜歡這種複雜又隱含問題的方式，當然我們有更好的實現執行緒安全的單例模式的辦法。

④餓漢式 static final field

餓漢式其實是一種比較形象的稱謂。既然餓，那麼在建立物件例項的時候就比較著急，餓了嘛，於是在裝載類的時候就建立物件例項。

這種方法非常簡單，因為單例的例項被宣告成 static 和 final 變量了，在第一次載入類到記憶體中時就會初始化，所以建立例項本身是執行緒安全的。

public class Singleton{
    //類載入時就初始化
    private static final Singleton instance = new Singleton();

    private Singleton(){}

    public static Singleton getInstance(){
        return instance;
    }
}

缺點是它不是一種懶載入模式（lazy initialization），單例會在載入類後一開始就被初始化，即使客戶端沒有呼叫 getInstance()方法。

餓漢式的建立方式在一些場景中將無法使用：譬如 Singleton 例項的建立是依賴引數或者配置檔案的，在 getInstance() 之前必須呼叫某個方法設定引數給它，那樣這種單例寫法就無法使用了。

⑤靜態內部類 static nested class

這種方法也是《Effective 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; 
    }  
}

這種寫法仍然使用JVM本身機制保證了執行緒安全問題。由於靜態單例物件沒有作為Singleton的成員變數直接例項化，因此類載入時不會例項化Singleton，第一次呼叫getInstance()時將載入內部類SingletonHolder，在該內部類中定義了一個static型別的變數INSTANCE ，此時會首先初始化這個成員變數，由Java虛擬機器來保證其執行緒安全性，確保該成員變數只能初始化一次。由於getInstance()方法沒有任何執行緒鎖定，因此其效能不會造成任何影響。

由於 SingletonHolder 是私有的，除了 getInstance() 之外沒有辦法訪問它，因此它是懶漢式的；同時讀取例項的時候不會進行同步，沒有效能缺陷；也不依賴 JDK 版本。

⑥列舉 Enum

用列舉寫單例實在太簡單了！這也是它最大的優點。下面這段程式碼就是宣告列舉例項的通常做法。

public class EasySingleton {

public static EasySingleton getinstance() {
return SingleTon.INSTANCE.getinstance();
}
public void test() {
System.out.print("666");
}

private static enum SingleTon{
INSTANCE;
private EasySingleton getinstance(){
return new EasySingleton();
}
}

我們可以通過EasySingleton.INSTANCE來訪問例項，這比呼叫getInstance()方法簡單多了。建立列舉預設就是執行緒安全的，所以不需要擔心double checked locking，而且還能防止反序列化導致重新建立新的物件。而且列舉單例可以自己處理序列化（

傳統的單例模式的另外一個問題是一旦你實現了serializable介面，他們就不再是單例的了，因為readObject()方法總是返回一個 新的例項物件，就像java中的構造器一樣。你可以使用readResolve()方法來避免這種情況，通過像下面的例子中這樣用單例來替換新建立的實 例：

//readResolve to prevent another instance of SingletonprivateObject readResolve(){returnINSTANCE;}

如果你的單例類包含狀態的話就變的更復雜了，你需要把他們置為transient狀態，但是用列舉單例的話，序列化就不要考慮了。

三、總結

一般來說，單例模式有五種寫法：懶漢、餓漢、雙重檢驗鎖、靜態內部類、列舉。上述所說都是執行緒安全的實現，上文中第一種方式執行緒不安全，排除。

一般情況下直接使用餓漢式就好了，如果明確要求要懶載入（lazy initialization）傾向於使用靜態內部類。如果涉及到反序列化建立物件時會試著使用列舉的方式來實現單例。