一文搞懂設計模式—單例模式
在軟件開發中，有些對象我們只需要一個實例，通過單例模式可以確保一個類只有一個實例，并提供了全局訪問點以便其他對象可以使用該實例。本文將介紹單例模式的使用場景、實現方式和總結。
單例模式屬于創建型設計模式，它限制一個類只能創建一個實例。這個實例可以通過全局訪問點來獲取，從而確保所有代碼都共享同一個實例。
Spring 框架應用中的 ApplicationContext 就是單例模式中的餓漢式。
單例模式在很多場景下都有應用，比如線程池、數據庫連接池、配置對象等。通過使用單例模式，可以降低系統中對象的數量，減少資源開銷，并且方便管理和控制這些共享的實例。
優點
- 由于單例模式在內存中只有一個實例，減少了內存開支，特別是一個對象需要頻繁地創建、銷毀時，而且創建或銷毀時性能又無法優化，單例模式的優勢就非常明顯。
- 由于單例模式只生成一個實例，所以減少了系統的性能開銷，當一個對象的產生需要比較多的資源時，如讀取配置、產生其他依賴對象時，則可以通過在應用啟動時直接產生一個單例對象，然后用永久駐留內存的方式來解決（在Java EE中采用單例模式時需要注意JVM 垃圾回收機制）。
- 單例模式可以避免對資源的多重占用，例如一個寫文件動作，由于只有一個實例存在內存中，避免對同一個資源文件的同時寫操作。
- 單例模式可以在系統設置全局的訪問點，優化和共享資源訪問，例如可以設計一個單例類，負責所有數據表的映射處理。
缺點
- 單例模式一般沒有接口，擴展很困難，若要擴展，除了修改代碼基本上沒有第二種途 徑可以實現。單例模式為什么不能增加接口呢？因為接口對單例模式是沒有任何意義的，它要求“自行實例化”，并且提供單一實例、接口或抽象類是不可能被實例化的。當然，在特殊情況下，單例模式可以實現接口、被繼承等，需要在系統開發中根據環境判斷。
- 單例模式對測試是不利的，在并行開發環境中，如果單例模式沒有完成，是不能進行測試的，沒有接口也不能使用mock的方式虛擬一個對象。
- 單例模式與單一職責原則有沖突。一個類應該只實現一個邏輯，而不關心它是否是單例的，是不是要單例取決于環境，單例模式把“要單例”和業務邏輯融合在一個類中。
使用場景
為什么要用單例模式？
- 單例模式節省公共資源
比如：大家都要喝水，但是沒必要每人家里都打一口井是吧，通常的做法是整個村里打一個井就夠了，大家都從這個井里面打水喝。
對應到我們計算機里面，像日志管理、打印機、數據庫連接池、應用配置。
- 單例模式方便控制
就像日志管理，如果多個人同時來寫日志，你一筆我一筆那整個日志文件都亂七八糟，如果想要控制日志的正確性，那么必須要對關鍵的代碼進行上鎖，只能一個一個按照順序來寫，而單例模式只有一個人來向日志里寫入信息方便控制，避免了這種多人干擾的問題出現。
單例模式適用于以下場景：
- 當一個類只需要一個實例時。
- 當多個對象需要共享同一個實例時。
- 當創建實例需要耗費大量資源時。
單例模式的應用場景之一：日志記錄器。
public class Logger {
private static Logger instance;
private Logger() {
// 私有構造方法，防止外部實例化
}
public static synchronized Logger getInstance() {
if (instance == null) {
instance = new Logger();
}
return instance;
}
public void log(String message) {
System.out.println("Log: " + message);
}
}在上述示例中，Logger 類只能創建一個實例。通過 getInstance() 靜態方法，我們可以獲取該實例，并且在需要記錄日志的地方調用 log 方法進行日志記錄。
序列化對單例模式的破壞
序列化可能會破壞某些單例模式實現方式，特別是那些使用懶加載或延遲初始化的方式。在進行反序列化時，會創建一個新的對象實例，從而破壞了原本的單例特性。
以下是一個簡單的示例代碼，演示了序列化對懶漢式單例模式的影響：
public class Singleton implements Serializable {
private static Singleton instance;
private Singleton() {
// 私有構造方法
}
public static Singleton getInstance() {
if (instance == null) {
instance = new Singleton();
}
return instance;
}
public static void main(String[] args) {
Singleton singleton1 = Singleton.getInstance();
try {
// 將singleton1對象序列化到文件中
ObjectOutputStream outputStream = new ObjectOutputStream(new FileOutputStream("singleton.ser"));
outputStream.writeObject(singleton1);
outputStream.close();
// 從文件中反序列化出一個新對象
ObjectInputStream inputStream = new ObjectInputStream(new FileInputStream("singleton.ser"));
Singleton singleton2 = (Singleton) inputStream.readObject();
inputStream.close();
// 比較兩個對象是否相同
System.out.println("singleton1: " + singleton1.hashCode());
System.out.println("singleton2: " + singleton2.hashCode());
} catch (Exception e) {
e.printStackTrace();
}
}
}輸出：
singleton1: 868693306
singleton2: 625576447運行以上代碼，輸出結果會顯示 singleton1 和 singleton2 的哈希碼不同，說明反序列化過程創建了一個新的對象實例，破壞了單例模式。
要解決這個問題，可以使用枚舉方式實現單例模式，或者可以在類中添加一個 readResolve() 方法，并返回單例實例。這樣在反序列化時會調用該方法，從而確保只返回單例對象：
private Object readResolve() throws ObjectStreamException {
return instance;
}在上述示例的 Singleton 類中添加 readResolve() 方法后，再運行代碼，輸出結果將會顯示 singleton1 和 singleton2 的哈希碼相同，保證了單例模式的正確性。readResolve() 方法能夠讓我們控制反序列化時返回的對象，從而避免破壞單例特性。
實現方式
單例模式的實現有多種方式，如下所示：
餓漢式
public class EagerSingleton {
//確保對象實例只有一個
private static final EagerSingleton instance = new EagerSingleton();
// 私有構造方法，防止外部實例化
private EagerSingleton() {
}
//以靜態方法返回實例
public static EagerSingleton getInstance() {
return instance;
}
}優點：
- 線程安全：由于在類加載時就創建了實例，所以不會出現多線程并發訪問時創建多個實例的問題。
- 簡單直觀：餓漢模式的實現相對簡單，代碼易于理解和維護。
- 性能高：由于實例在類加載時就創建了，因此獲取實例的速度較快。
缺點：
- 不能懶加載：由于實例在類加載時就創建了，即使在某些情況下并不需要使用該實例，也會占用一定的資源。
餓漢模式適用于在程序運行期間始終需要使用的實例，并且對性能要求較高的場景。但是需要注意內存浪費的問題。
懶漢式
public class LazySingleton {
private static LazySingleton instance;
// 私有構造方法，防止外部實例化
private LazySingleton() {
}
public static LazySingleton getInstance() {
if (instance == null) {
instance = new LazySingleton();
}
return instance;
}
}在懶漢式中，實例在第一次被使用時才會被創建。但是當多個線程同時調用 getInstance() 方法時，可能會導致創建多個實例。存在線程安全問題。
優點：
- 延遲加載：懶漢模式在第一次使用時才會創建實例，可以避免不必要的資源消耗。
缺點：
- 線程安全性需要額外考慮：在最簡單的懶漢模式實現中，當多個線程同時調用 getInstance() 方法時，可能會創建多個實例。為了解決這個問題，可以使用同步關鍵字或者其他線程安全的方式進行控制，但這可能會影響性能。
- 性能開銷：由于懶漢模式需要在獲取實例時進行判斷和創建，會帶來一定的性能開銷，特別是在高并發的情況下。
總體來說，懶漢模式適用于在程序運行期間可能不會立即使用到實例的情況，可以實現延遲加載。但是需要注意線程安全性和性能開銷的問題，在多線程環境下要特別小心處理。
如果要保證懶漢模式的線程安全性，則需要加鎖解決線程同步問題。
雙重校驗鎖
public class LazySingleton{
/**
* volatile 關鍵字可以保證線程間變量的可見性，還有一個作用就是阻止局部重排序的發生
*/
private volatile static LazySingleton INSTANCE = null;
private LazySingleton(){}
public static LazySingleton getInstance(){
if(INSTANCE == null)
{
synchronized(LazySingleton.class){
if(INSTANCE == null){
INSTANCE = new LazySingleton();
}
}
return INSTANCE;
}
}
}雙層校驗鎖的懶漢模式可以確保在多線程環境下僅創建一個實例，并保證線程安全性。具體解釋如下：
- 首先，如果實例已經被創建，則直接返回該實例，避免了不必要的同步開銷。
- 當第一個線程到達getInstance()方法時，會檢查實例是否為空。由于在多線程環境下可能有多個線程同時通過這一判斷，因此需要在 synchronized 關鍵字內再次進行空檢查。
- 在進入 synchronized 塊之前，使用雙重檢查來確保只有第一個線程能夠創建實例。即使有其他線程在第一個線程進入 synchronized 塊之后搶占CPU資源，它們也會發現實例已經被創建，從而避免重復創建實例。
- 使用volatile關鍵字修飾 INSTANCE 變量，可以確保變量的可見性，在多線程環境下，一個線程修改了 INSTANCE 的值，其他線程能夠立即看到最新的值，避免了指令重排序帶來的問題。
靜態內部類
基于靜態內部類實現線程安全，性能比雙重檢查鎖要好。
public class Singleton {
private static class LazyHolder {
private static final Singleton INSTANCE = new Singleton();
}
private Singleton (){
/*為了避免反射破壞單例，需要在構造方法中增加限制，一旦出現多次重復創建，直接拋出異常*/
if (null != LazyHolder.INSTANCE) {
throw new RuntimeException("創建Singleton異常，不允許創建多個實例！");
}
}
/**
* 調用靜態方法的時候會先加載Singleton類，靜態內部類只有在使用的時候才會被加載。
* 而ClassLoader加載的時候是單個線程的。所以既能夠實現需要的時候才被加載，也能夠實現線程安全。
*/
public static final Singleton getInstance() {
return LazyHolder.INSTANCE;
}
}這種方式利用了類加載機制來保證只創建一個instance實例，從而保證線程安全性。具體解釋如下：
- 靜態內部類 LazyHolder 只有在 getInstance() 方法被調用時才會被加載，從而實現了延遲加載的效果。
- 類加載是由 ClassLoader 負責的，ClassLoader 在加載類的過程中是單線程進行的，因此在加載 LazyHolder 類時是線程安全的。
- LazyHolder 類中的 INSTANCE 是final修飾的，保證了實例的唯一性和不可更改性。
- 在 Singleton 的構造方法中，通過判斷 LazyHolder.INSTANCE 是否為 null 來防止通過反射手段創建多個實例。如果嘗試重復創建實例，將拋出異常。
枚舉式
枚舉方式理論上是實現單例模式的最佳方式，這種方式也是《Effective Java》的作者 Josh Bloch 提倡的方式。
public enum Singleton {
INSTANCE;
// 其他成員方法和屬性
public void doSomething() {
// 實現具體的功能
}
}枚舉方式實現的單例模式能夠保證線程安全，原因如下：
- 枚舉類型在Java中是線程安全的，線程安全性由JVM本身來保證，它的實例在類加載過程中被初始化，并且只會被初始化一次。這意味著在多線程環境下，不會出現多個線程創建多個實例的情況。
- 枚舉實例是在類加載時被創建的，而且是靜態常量，因此在整個應用程序生命周期內，只會存在一個實例。無論何時訪問枚舉實例，都會返回同一個對象。
相比前面的實現方式，枚舉方式有兩大優點：
- 防止反射攻擊和序列化破壞：枚舉本身就具有防止反射攻擊和序列化破壞的特性。枚舉實例的創建由JVM自動管理，不可通過反射調用私有構造函數創建新的實例，同時枚舉類型默認實現了Serializable接口，因此也能夠防止序列化破壞單例。
- 簡潔明了：使用枚舉方式實現單例模式非常簡潔清晰，代碼量少，易于理解和維護。
總結
選擇單例模式的實現方式取決于具體的需求和場景。下面是對不同實現方式的一些建議：
- 餓漢式：如果單例對象在程序運行期間始終需要存在，并且占用資源較小，則可以考慮使用餓漢式。它能夠保證在任何時候都能獲得單例對象，但可能會提前加載實例造成資源浪費。
- 懶漢式：如果單例對象在程序中的使用并不頻繁，或者占用資源較大，希望在需要時才進行初始化，可以選擇懶漢式。懶漢式能夠延遲加載實例，節省資源，但需要考慮線程安全性。
- 雙重校驗鎖（Double-Checked Locking）：這種方式結合了懶漢式和餓漢式的優點，即實現了延遲加載和線程安全。適用于資源消耗較大、需要延遲加載的情況。
- 靜態內部類：靜態內部類方式實現的單例模式具有延遲加載和線程安全的特點，同時也解決了雙重校驗鎖的問題。適用于資源消耗較小、只在需要時才進行初始化的情況。
- 枚舉方式：枚舉方式是最簡潔且安全可靠的單例實現方式，適用于任何情況。它具有線程安全性、實例唯一性和防止反射攻擊、序列化破壞等優點。
總而言之，單例模式作為一種常見的設計模式，在軟件開發中有著廣泛的應用。選擇適合的實現方式，并根據具體需求進行靈活運用，將有助于提升系統的性能和可維護性。
選擇合適的單例模式實現方式需要綜合考慮需求、資源消耗、線程安全性以及代碼簡潔性等因素。無論選擇哪種方式，保證線程安全是非常重要的，同時也需要注意防止反射攻擊和序列化破壞。
