概念

單例模式是一種常用的軟件設計模式。在應用這個模式時，單例對象的類必須保證只有一個實例存在。本文就從單例模式的兩種構建方式來了解一下單例。以下會給出多種單例的實現，有正確的、也有存在缺陷的。最后會總結各個方式優缺點。

分類

1. 餓漢式單例模式：指全局的單例實例在類加載時就主動創建實例。
2. 懶漢式單例模式：指全局的單例實例在第一次被使用時才創建實例，不使用時不創建實例。

實現方式

1。餓漢式：（記為 實現-1）

形象的描述就是“直接”，想象一下一名餓漢在吃東西時的樣子。食物到面前就開吃，簡單粗暴。而代碼中的體現就是一被加載就構建。實現起來也是簡單粗暴，沒有缺陷，唯一的不足就是耗費資源。因為就算這個單例沒被使用到，它也會被實例化，占用內存。

示例代碼

public class Singleton {
    private static Singleton instance= new Singleton();
      
    private Singleton() {
    }
    
    public static Singleton getInstance() {
        return instance;
    }
}

餓漢式的單例模式上面代碼就已經實現了，我們平時使用時是這樣的：Singleton.getInstance();
當方法被調用時Singleton第一次被使用，此時類被加載。類加載過程中靜態變量被初始化，instance 實例也就是在這時候被構建。

2.懶漢式

懶漢式通俗的解釋起來就是，懶人干的事情，懶人做事就是需要做的時候才去做。在代碼上的體現就是延時加載。

下面來一步步從 缺陷到 完善 實現懶漢式單例模式：

• 實現 - 2 （存在缺陷的實現）

我們經常會寫以下代碼來實現單例模式，但是這種實現方式存在弊端：線程不安全。

示例代碼

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

我們來分析缺陷所在：

假設線程1、2同時調用getInstance()，線程1準備執行 instance= new Singleton(); 時被線程2預占。因為此時insteance 還未被示例話，所以線程2可以執行完整個getInstance()方法，返回了Singleton對象引用。此時線程1在它停止的地方啟動，執行接下來的代碼，由于已經進行過了非空判斷，所以接下來就錯誤的再次實例化了一個Singleton對象。此時就示例化了兩個Singleton對象。反之，如果能保證是單線程使用此單例對象，這種實現方式是沒有問題的。

• 實現 - 3 （對實現 - 2進行改進）

實現2中既然存在線程不安全的問題，那么很容易就想到一個處理方法，那就是加鎖。

示例代碼

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

這種實現與 實現2 相比較，差別就在于一個同步鎖。加了鎖的getInstance() 可以保證線程安全，并且也實現了單例。
這一種正確的單例實現方式，但是由于對 getInstance()做了同步處理，synchronized將導致性能開銷。

分析這種實現發現其實只有在第一次調用方法時才需要同步。（此處自行理解下）

由于只有第一次調用執行了 instance= new Singleton()，而只有此行代碼需要同步，因此就無需對后續調用使用同步。除了第一次調用外其他的調用都只需要判斷 instance是否為 null，并將其返回。多線程能夠安全并發地執行除第一次調用外的所有調用。
由于該方法是synchronized 的，需要為該方法的每一次調用付出同步的代價，即使只有第一次調用需要同步。所以如果getInstance()被多個線程頻繁的調用，將會導致程序執行性能的下降。反之，如果getInstance()不會被多個線程頻繁的調用，那么這個延遲初始化方案將能提供令人滿意的性能。

既然有性能上的不足，那么我們偉大的程序猿自然會想出優化性能的方法。所以就有了接下的的這種實現 雙重檢查鎖定

• 實現 - 4 （對實現 - 3進行性能優化后的實現 - 雙重檢查鎖定 double-checked locking）

先聲明，雙重檢查鎖定這種實現方式是一種存在漏洞的單例實現

示例代碼

public class Singleton {
    private final static Singleton instance;
    public static Singleton getInstance() {
        if (instance == null) {
            synchronized (Singleton.class) {
                if (instance== null) {
                    instance= new Singleton(); // 問題出現位置
                }
            }
        }
        return instance;
    }
}

上面的代碼就是 雙重檢查鎖定的實現方式。

分析 實現 - 4 的代碼：

如果第一次檢查instance不為null，那么就不需要執行下面的加鎖和初始化操作。因此可以大幅降低synchronized帶來的性能開銷。上面代碼表面上看起來，似乎兩全其美：

1. 在多個線程情況下同一時間調用getInstance()時，會通過加鎖來保證只有一個線程能創建對象。

2.在對象創建好之后，執行getInstance()將不需要每次都獲取鎖，直接返回已創建好的對象，優化了實現-3 中多次獲取鎖導致的性能消耗。

雙重檢查鎖定看起來似乎很完美，但這是一個錯誤的優化！在線程執行到第4行代碼讀取到instance不為null時，instance引用的對象有可能還沒有完成初始化。

該問題的具體分析請看這里 ：http://www.infoq.com/cn/articles/double-checked-locking-with-delay-initialization

我在這里做簡單的分析并給出解決方式

前面的雙重檢查鎖定示例代碼的第7行instance = new Singleton()創建一個對象。這一行代碼可以分解為如下的三行偽代碼：

memory = allocate();   //1：分配對象的內存空間
ctorInstance(memory);  //2：初始化對象
instance = memory;     //3：設置instance指向剛分配的內存地址

上面三行偽代碼中的2和3之間，可能會被重排序（在一些JIT編譯器上，這種重排序是真實發生的，詳情見參考文獻1的“Out-of-order writes”部分）。2和3之間重排序之后的執行時序如下：

memory = allocate();   //1：分配對象的內存空間
instance = memory;     //3：設置instance指向剛分配的內存地址
                       //注意，此時對象還沒有被初始化！
ctorInstance(memory);  //2：初始化對象

根據《The Java Language Specification, Java SE 7 Edition》（后文簡稱為java語言規范），所有線程在執行java程序時必須要遵守intra-thread semantics。intra-thread semantics保證重排序不會改變單線程內的程序執行結果。換句話來說，intra-thread semantics允許那些在單線程內，不會改變單線程程序執行結果的重排序。上面三行偽代碼的2和3之間雖然被重排序了，但這個重排序并不會違反intra-thread semantics。這個重排序在沒有改變單線程程序的執行結果的前提下，可以提高程序的執行性能。

為了更好的理解intra-thread semantics，請看下面的示意圖（假設一個線程A在構造對象后，立即訪問這個對象）：

重排序圖示.png

如上圖所示，只要保證2排在4的前面，即使2和3之間重排序了，也不會違反intra-thread semantics。
下面，再讓我們看看多線程并發執行的時候的情況。請看下面的示意圖：

多線程重排序圖示.png

這么說有點抽象，我們回到代碼分析

示例代碼第七行 instance= new Singleton() ，此處若是發生重排序，對象還未被初始化完成。此時另一個并發的線程B就有可能在 第4行判斷 instance 不為 null 。那么線程B就將訪問未完成初始化的對象。這就是錯誤所在。

在知曉了問題發生的根源之后，我們可以想出兩個辦法來實現線程安全的延遲初始化：

1. 不允許2和3重排序；

2. 允許2和3重排序，但不允許其他線程“看到”這個重排序。

既然想到了方法，那么就用代碼來實現。

• 解決方案1：實現 - 5 （基于volatile的雙重檢查鎖定）

示例代碼

public class Instance {
    private volatile static Instance instance;

    private Instance (){ }

    public static Instance getInstance() {
        if (instance== null) {
            synchronized (SafeDoubleCheckedLocking.class) {
                if (instance== null)
                    instance= new Instance();//instance 為volatile，現在沒問題了
            }
        }
        return instance;
    }
}

注意，這個解決方案需要JDK5或更高版本（因為從JDK5開始使用新的JSR-133內存模型規范，這個規范增強了volatile的語義）。當聲明對象的引用為volatile后，“問題的根源”的三行偽代碼中的2和3之間的重排序，在多線程環境中將會被禁止。禁止后，線程B在進行第一次 instance == null 判斷時就不會為true， 將按如下的時序執行：

image.png

這個方案本質上是通過禁止上圖中的2和3之間的重排序，來保證線程安全的延遲初始化。

解決方案2：實現 - 6（基于類初始化的解決方案 - Initialization On Demand Holder idiom）

示例代碼

public class Singleton {   
    private Singleton() {
    }
    private static class LazyHolder {
        static final Singleton INSTANCE = new Singleton();
    }
    public static Singleton getInstance() {
        return LazyHolder.INSTANCE; // 這里將導致Singleton類被初始化
    }
}

JVM在類的初始化階段（即在Class被加載后，且被線程使用之前），會執行類的初始化。在執行類的初始化期間，JVM會去獲取一個鎖。這個鎖可以同步多個線程對同一個類的初始化。相比其他實現方案（如double-checked locking等），該技術方案的實現代碼較為簡潔，并且在所有版本的編譯器中都是可行的。

補充內容

關于實現 - 6中，static final Instance instance 域的訪問權限為什么是包級私有可以讀:Initialization On Demand Holder idiom的實現探討

各種實現方式的優缺點：

• 餓漢式（實現 - 1） 單例實例在類裝載時就構建，急切初始化。

  • 優點：
    • 線程安全
    • 在類加載的同時已經創建好一個靜態對象，調用時反應速度快。
  • 缺點
    • 資源效率不高，getInstance()可能永遠不會執行到，但執行該類的其他靜態方法或者加載了該類（class.forName)，那么這個實例仍然初始化。

• 懶漢式 （實現 2 - 6）單例實例在第一次被使用時構建（調用 getInsteance()），延遲初始化。

  • 實現 - 2（缺陷實現）：這種實現方式存在線程不安全的缺陷，不推薦使用。但若能保證處于單線程中，可以使用這種實現方式。
  • 實現 - 3（耗資源實現）：這種實現方式對實現-2中線程不安全的缺陷進行了處理。
    • 優點：資源利用率高，不執行getInstance()就不會被實例，可以執行該類的其他靜態方法。
    • 缺點：第一次加載時不夠快，多線程使用不必要的同步開銷大
  • 實現 - 4（問題實現）：雙重檢查鎖定，這是對實現 - 3的一種優化實現，但是存在重排序導致獲取到未初始化的單例對象的問題
  • 實現 - 5：雙重檢查鎖定+volatile
    • 優點：資源利用率高，不執行getInstance()就不會被實例，可以執行該類的其他靜態方法。
    • 缺點：第一次加載時反應不快。實現起來代碼較為復雜。
    • 注意點：jdk1.5版本后volatile關鍵字才能正確的工作。Android平臺不同當心這個問題，一般Android都是jdk1.6以上。
  • 實現 - 6：靜態內部類
    • 優點：資源利用率高，不執行getInstance()就不會被實例，可以執行該類的其他靜態方法。實現代碼較為簡潔
    • 缺點：第一次加載時反應不快。

總結：

1. 延遲初始化降低了初始化類或創建實例的開銷，但增加了訪問被延遲初始化的字段的開銷(鎖)。在大多數時候，正常的初始化要優于延遲初始化。
2. 如果確實需要對實例字段使用線程安全的延遲初始化，請使用上面介紹的基于volatile的延遲初始化的方案（實現 - 5）；
3. 如果確實需要對靜態字段使用線程安全的延遲初始化，請使用上面介紹的基于類初始化的方案。（實現 - 6）
4. 一般采用餓漢式（實現 - 1），若對資源十分在意建議采用靜態內部類（實現 - 6）。