Java與設計模式（十二）創建型--單例模式

1. 一、單例模式的動機

對於一個軟件系統的某些類而言，我們無須創建多個實例。舉個大家都熟知的例子——Windows任務管理器，我們可以做一個這樣的嘗試，在Windows的“任務欄”的右鍵彈出菜單上多次點擊“啓動任務管理器”，看能否打開多個任務管理器窗口？通常情況下，無論我們啓動任務管理多少次，Windows系統始終只能彈出一個任務管理器窗口，也就是說在一個Windows系統中，任務管理器存在唯一性。爲什麼要這樣設計呢？我們可以從以下兩個方面來分析：

• 其一，如果能彈出多個窗口，且這些窗口的內容完全一致，全部是重複對象，這勢必會浪費系統資源，任務管理器需要獲取系統運行時的諸多信息，這些信息的獲取需要消耗一定的系統資源，包括CPU資源及內存資源等，浪費是可恥的，而且根本沒有必要顯示多個內容完全相同的窗口；

• 其二，如果彈出的多個窗口內容不一致，問題就更加嚴重了，這意味着在某一瞬間系統資源使用情況和進程、服務等信息存在多個狀態，例如任務管理器窗口A顯示“CPU使用率”爲10%，窗口B顯示“CPU使用率”爲15%，到底哪個纔是真實的呢？給用戶帶來誤解，更不可取。由此可見，確保Windows任務管理器在系統中有且僅有一個非常重要。

  回到實際開發中，我們也經常遇到類似的情況，爲了節約系統資源，有時需要確保系統中某個類只有唯一一個實例，當這個唯一實例創建成功之後，我們無法再創建一個同類型的其他對象，所有的操作都只能基於這個唯一實例。爲了確保對象的唯一性，我們可以通過單例模式來實現，這就是單例模式的動機所在

二、代碼示例

懶漢式，線程不安全

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

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

這種方式是最基本的實現方式，這種實現最大的問題就是不支持多線程。因爲沒有加鎖 synchronized，所以嚴格意義上它並不算單例模式。這種方式 lazy loading 很明顯，不要求線程安全，在多線程不能正常工作

懶漢式，線程安全

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

這種方式具備很好的 lazy loading，能夠在多線程中很好的工作，但是，效率很低，99% 情況下不需要同步。

優點：第一次調用才初始化，避免內存浪費。

缺點：必須加鎖 synchronized 才能保證單例，但加鎖會影響效率。

getInstance() 的性能對應用程序不是很關鍵（該方法使用不太頻繁）。

餓漢式

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

這種方式比較常用，但容易產生垃圾對象。

• 優點：沒有加鎖，執行效率會提高。
• 缺點：類加載時就初始化，浪費內存。

它基於 classloder 機制避免了多線程的同步問題，不過，instance 在類裝載時就實例化，雖然導致類裝載的原因有很多種，在單例模式中大多數都是調用 getInstance 方法， 但是也不能確定有其他的方式（或者其他的靜態方法）導致類裝載，這時候初始化 instance 顯然沒有達到 lazy loading 的效果。

雙檢鎖/雙重校驗鎖（DCL，即 double-checked locking）

public class Singleton {  
    private volatile static Singleton singleton;  
    private Singleton (){}  
    public static Singleton getInstance() {  
    if (singleton == null) {  
        synchronized (Singleton.class) {  
        if (singleton == null) {  
            singleton = new Singleton();  
        }  
        }  
    }  
    return singleton;  
    }  
}  

這種方式採用雙鎖機制，安全且在多線程情況下能保持高性能。
getInstance() 的性能對應用程序很關鍵。

登記式/靜態內部類

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 時只有一個線程，它跟第 3 種方式不同的是：第 3 種方式只要 Singleton 類被裝載了，那麼 instance 就會被實例化（沒有達到 lazy loading 效果），而這種方式是 Singleton 類被裝載了，instance 不一定被初始化。因爲 SingletonHolder 類沒有被主動使用，只有通過顯式調用 getInstance 方法時，纔會顯式裝載 SingletonHolder 類，從而實例化 instance。想象一下，如果實例化 instance 很消耗資源，所以想讓它延遲加載，另外一方面，又不希望在 Singleton 類加載時就實例化，因爲不能確保 Singleton 類還可能在其他的地方被主動使用從而被加載，那麼這個時候實例化 instance 顯然是不合適的。這個時候，這種方式相比第 3 種方式就顯得很合理

枚舉

public enum Singleton {  
    INSTANCE;  
    public void whateverMethod() {  
    }  
}  

這種實現方式還沒有被廣泛採用，但這是實現單例模式的最佳方法。它更簡潔，自動支持序列化機制，絕對防止多次實例化。

這種方式是 Effective Java 作者 Josh Bloch 提倡的方式，它不僅能避免多線程同步問題，而且還自動支持序列化機制，防止反序列化重新創建新的對象，絕對防止多次實例化。不過，由於 JDK1.5 之後才加入 enum 特性，用這種方式寫不免讓人感覺生疏，在實際工作中，也很少用。

不能通過 reflection attack 來調用私有構造方法。

使用經驗

一般情況下，不建議使用第 1 種和第 2 種懶漢方式，建議使用第 3 種餓漢方式。只有在要明確實現 lazy loading 效果時，纔會使用第 5 種登記方式。如果涉及到反序列化創建對象時，可以嘗試使用第 6 種枚舉方式。如果有其他特殊的需求，可以考慮使用第 4 種雙檢鎖方式。

五、單例模式總結

單例模式作爲一種目標明確、結構簡單、理解容易的設計模式，在軟件開發中使用頻率相當高，在很多應用軟件和框架中都得以廣泛應用。

主要優點

• 單例模式提供了對唯一實例的受控訪問。因爲單例類封裝了它的唯一實例，所以它可以嚴格控制客戶怎樣以及何時訪問它。
• 由於在系統內存中只存在一個對象，因此可以節約系統資源，對於一些需要頻繁創建和銷燬的對象單例模式無疑可以提高系統的性能。
• 允許可變數目的實例。基於單例模式我們可以進行擴展，使用與單例控制相似的方法來獲得指定個數的對象實例，既節省系統資源，又解決了單例單例對象共享過多有損性能的問題。

主要缺點

• 由於單例模式中沒有抽象層，因此單例類的擴展有很大的困難。
• 單例類的職責過重，在一定程度上違背了“單一職責原則”。因爲單例類既充當了工廠角色，提供了工廠方法，同時又充當了產品角色，包含一些業務方法，將產品的創建和產品的本身的功能融合到一起。

適用場景

• 系統只需要一個實例對象，如系統要求提供一個唯一的序列號生成器或資源管理器，或者需要考慮資源消耗太大而只允許創建一個對象。
• 客戶調用類的單個實例只允許使用一個公共訪問點，除了該公共訪問點，不能通過其他途徑訪問該實例。

六、單例模式與垃圾回收

當一個單例的對象長久不用時，會不會被jvm的垃圾收集機制回收。

我的回答:不會

hotspot虛擬機的垃圾收集算法使用根搜索算法。這個算法的基本思路是：對任何”活”的對象，一定能最終追溯到其存活在堆棧或靜態存儲區之中的引用。通過一系列名爲根（GC Roots）的引用作爲起點，從這些根開始搜索，經過一系列的路徑，如果可以到達java堆中的對象，那麼這個對象就是”活”的，是不可回收的。可以作爲根的對象有：

• 虛擬機棧（棧楨中的本地變量表）中的引用的對象。
• 方法區中的類靜態屬性引用的對象。
• 方法區中的常量引用的對象。
• 本地方法棧中JNI的引用的對象。

方法區是jvm的一塊內存區域，用來存放類相關的信息。很明顯，java中單例模式創建的對象被自己類中的靜態屬性所引用，符合第二條，因此，單例對象不會被jvm垃圾收集。

雖然jvm堆中的單例對象不會被垃圾收集，但是單例類本身如果長時間不用會不會被收集呢？因爲jvm對方法區也是有垃圾收集機制的。如果單例類被收集，那麼堆中的對象就會失去到根的路徑，必然會被垃圾收集掉。hotspot虛擬機對方法區的垃圾收集方法，jvm卸載類的判定條件如下：

• 該類所有的實例都已經被回收，也就是java堆中不存在該類的任何實例。
• 加載該類的ClassLoader已經被回收。
• 該類對應的java.lang.Class對象沒有任何地方被引用，無法在任何地方通過反射訪問該類的方法。

只有三個條件都滿足，jvm纔會在垃圾收集的時候卸載類。顯然，單例的類不滿足條件一，因此單例類也不會被卸載。也就是說，只要單例類中的靜態引用指向jvm堆中的單例對象，那麼單例類和單例對象都不會被垃圾收集，依據根搜索算法，對象是否會被垃圾收集與未被使用時間長短無關，僅僅在於這個對象是不是”活”的。假如一個對象長久未使用而被回收，那麼收集算法應該是最近最長未使用算法，最近最長未使用算法一般用在操作系統的內外存交換中，如果用在虛擬機垃圾回收中，豈不是太不安全了？