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