本文實踐代碼倉庫：https://github.com/goSilver/my_practice

一、定義

單例模式是一種創(chuàng)建型設(shè)計模式，它確保一個類只有一個實例，并提供一個全局訪問點以訪問該實例。單例模式常用于需要共享資源或控制某個唯一資源的場景，例如數(shù)據(jù)庫連接、線程池等。

二、作用

單例模式可以確保在整個應(yīng)用程序中只有一個對象實例存在，從而方便地共享資源、管理狀態(tài)或控制某些操作。

從業(yè)務(wù)概念上，有些數(shù)據(jù)在系統(tǒng)中只應(yīng)該保存一份，就比較適合設(shè)計為單例類。比如，系統(tǒng)的配置信息類。除此之外，我們還可以使用單例解決資源訪問沖突的問題。

三、實現(xiàn)

要實現(xiàn)一個單例，我們需要關(guān)注的點無外乎下面幾個：

• 構(gòu)造函數(shù)需要是 private 訪問權(quán)限的，這樣才能避免外部通過 new 創(chuàng)建實例；
• 考慮對象創(chuàng)建時的線程安全問題；
• 考慮是否支持延遲加載；
• 考慮 getInstance() 性能是否高（是否加鎖）。

3.1 餓漢式

餓漢式的實現(xiàn)方式比較簡單。在類加載的時候，instance 靜態(tài)實例就已經(jīng)創(chuàng)建并初始化好了，所以，instance 實例的創(chuàng)建過程是線程安全的。不過，這樣的實現(xiàn)方式不支持延遲加載（在真正用到IdGenerator 的時候，再創(chuàng)建實例）。

如果實例資源初始化時間長、占用資源多，那么最好是采用餓漢式，將耗時的初始化操作提前到程序啟動時就完成，避免程序在運行中發(fā)生崩潰。

public class Hungry {private final AtomicLong id = new AtomicLong(0);/*** 類加載時就初始化*/private static final Hungry instance = new Hungry();private Hungry() {}public static Hungry getInstance() {return instance;}public long getId() {return id.incrementAndGet();}
}

3.2 懶漢式

懶漢式相對于餓漢式的優(yōu)勢是支持延遲加載。這種實現(xiàn)方式會導(dǎo)致頻繁加鎖、釋放鎖，以及并發(fā)度低等問題，頻繁的調(diào)用會產(chǎn)生性能瓶頸。

public class Lazy {private final AtomicLong id = new AtomicLong(0);private static Lazy instance;private Lazy() {}/*** 獲取實例的方法被synchronized關(guān)鍵字修飾* @return 實例*/public static synchronized Lazy getInstance() {if (instance == null) {instance = new Lazy();}return instance;}public long getId() {return id.incrementAndGet();}
}

3.3 雙重檢查

雙重檢測實現(xiàn)方式既支持延遲加載、又支持高并發(fā)的單例實現(xiàn)方式。**只要 instance 被創(chuàng)建之后，再調(diào)用 getInstance() 函數(shù)都不會進入到加鎖邏輯中。**所以，這種實現(xiàn)方式解決了懶漢式并發(fā)度低的問題。

public class DoubleCheck {private final AtomicLong id = new AtomicLong(0);/*** volatile關(guān)鍵字修飾* CPU 指令重排序可能導(dǎo)致在 IdGenerator 類的對象被關(guān)鍵字 new 創(chuàng)建并賦值給 instance 之后，還沒來得及初始化（執(zhí)行構(gòu)造函數(shù)中的代碼邏輯），就被另一個線程使用了。* 這樣，另一個線程就使用了一個沒有完整初始化的 IdGenerator 類的對象。* 要解決這個問題，我們只需要給 instance 成員變量添加 volatile 關(guān)鍵字來禁止指令重排序即可。*/private static volatile DoubleCheck instance;private DoubleCheck() {}/*** 雙重檢查* @return 實例*/public static DoubleCheck getInstance() {if (instance == null) {// 只有第一次才會執(zhí)行到這里，此處為類級別鎖synchronized (DoubleCheck.class) {if (instance == null) {instance = new DoubleCheck();}}}return instance;}public long getId() {return id.incrementAndGet();}
}

3.4 靜態(tài)內(nèi)部類

利用 Java 的靜態(tài)內(nèi)部類來實現(xiàn)單例。這種實現(xiàn)方式，既支持延遲加載，也支持高并發(fā)，實現(xiàn)起來也比雙重檢測簡單。

public class StaticInnerClass {private AtomicLong id = new AtomicLong(0);private StaticInnerClass() {}/*** 靜態(tài)內(nèi)部類* SingletonHolder 是一個靜態(tài)內(nèi)部類，當(dāng)外部類 IdGenerator 被加載的時候，并不會創(chuàng)建 SingletonHolder 實例對象。* 只有當(dāng)調(diào)用 getInstance() 方法時，SingletonHolder 才會被加載，這個時候才會創(chuàng)建 instance。* instance 的唯一性、創(chuàng)建過程的線程安全性，都由 JVM 來保證。所以，這種實現(xiàn)方法既保證了線程安全，又能做到延遲加載。*/private static class SingletonHolder {private static final StaticInnerClass instance = new StaticInnerClass();}public static StaticInnerClass getInstance() {return SingletonHolder.instance;}public long getId() {return id.incrementAndGet();}
}

3.5 枚舉

最簡單的實現(xiàn)方式，基于枚舉類型的單例實現(xiàn)。這種實現(xiàn)方式通過 Java 枚舉類型本身的特性，保證了實例創(chuàng)建的線程安全性和實例的唯一性。

public enum Enumm {/*** 實例*/INSTANCE;private final AtomicLong id = new AtomicLong(0);public long getId() {return id.incrementAndGet();}
}

四、總結(jié)

4.1 單例存在哪些問題？

1. 單例對 OOP 特性的支持不友好

一旦你選擇將某個類設(shè)計成到單例類，也就意味著放棄了繼承和多態(tài)這兩個強有力的面向?qū)ο筇匦?#xff0c;也就相當(dāng)于損失了可以應(yīng)對未來需求變化的擴展性。

2. 單例會隱藏類之間的依賴關(guān)系

通過構(gòu)造函數(shù)、參數(shù)傳遞等方式聲明的類之間的依賴關(guān)系，我們通過查看函數(shù)的定義，就能很容易識別出來。但是，單例類不需要顯示創(chuàng)建、不需要依賴參數(shù)傳遞，在函數(shù)中直接調(diào)用就可以了。如果代碼比較復(fù)雜，這種調(diào)用關(guān)系就會非常隱蔽。在閱讀代碼的時候，我們就需要仔細查看每個函數(shù)的代碼實現(xiàn)，才能知道這個類到底依賴了哪些單例類。

3. 單例對代碼的擴展性不友好

單例類只能有一個對象實例。如果未來某一天，我們需要在代碼中創(chuàng)建兩個實例或多個實例，那就要對代碼有比較大的改動。

4. 單例對代碼的可測試性不友好

單例模式的使用會影響到代碼的可測試性。如果單例類依賴比較重的外部資源，比如 DB，我們在寫單元測試的時候，希望能通過 mock 的方式將它替換掉。而單例類這種硬編碼式的使用方式，導(dǎo)致無法實現(xiàn) mock 替換。

5. 單例不支持有參數(shù)的構(gòu)造函數(shù)

單例不支持有參數(shù)的構(gòu)造函數(shù)，比如我們創(chuàng)建一個連接池的單例對象，我們沒法通過參數(shù)來指定連接池的大小。

4.2 單例有什么替代解決方案？

為了保證全局唯一，除了使用單例，我們還可以用靜態(tài)方法來實現(xiàn)。不過，靜態(tài)方法這種實現(xiàn)思路，并不能解決我們之前提到的問題。如果要完全解決這些問題，我們可能要從根上，尋找其他方式來實現(xiàn)全局唯一類了。比如，通過工廠模式、IOC 容器（比如 Spring IOC 容器）來保證，由程序員自己來保證（自己在編寫代碼的時候自己保證不要創(chuàng)建兩個類對象）。

有人把單例當(dāng)作反模式，主張杜絕在項目中使用。我個人覺得這有點極端。模式?jīng)]有對錯，關(guān)鍵看你怎么用。如果單例類并沒有后續(xù)擴展的需求，并且不依賴外部系統(tǒng)，那設(shè)計成單例類就沒有太大問題。對于一些全局的類，我們在其他地方 new 的話，還要在類之間傳來傳去，不如直接做成單例類，使用起來簡潔方便。