本文實(shí)踐代碼倉(cāng)庫(kù)：https://github.com/goSilver/my_practice

一、定義

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

二、作用

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

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

三、實(shí)現(xiàn)

要實(shí)現(xiàn)一個(gè)單例，我們需要關(guān)注的點(diǎn)無(wú)外乎下面幾個(gè)：

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

3.1 餓漢式

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

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

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

3.2 懶漢式

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

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

3.3 雙重檢查

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

public class DoubleCheck {private final AtomicLong id = new AtomicLong(0);/*** volatile關(guān)鍵字修飾* CPU 指令重排序可能導(dǎo)致在 IdGenerator 類的對(duì)象被關(guān)鍵字 new 創(chuàng)建并賦值給 instance 之后，還沒(méi)來(lái)得及初始化（執(zhí)行構(gòu)造函數(shù)中的代碼邏輯），就被另一個(gè)線程使用了。* 這樣，另一個(gè)線程就使用了一個(gè)沒(méi)有完整初始化的 IdGenerator 類的對(duì)象。* 要解決這個(gè)問(wèn)題，我們只需要給 instance 成員變量添加 volatile 關(guān)鍵字來(lái)禁止指令重排序即可。*/private static volatile DoubleCheck instance;private DoubleCheck() {}/*** 雙重檢查* @return 實(shí)例*/public static DoubleCheck getInstance() {if (instance == null) {// 只有第一次才會(huì)執(zhí)行到這里，此處為類級(jí)別鎖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)部類來(lái)實(shí)現(xiàn)單例。這種實(shí)現(xiàn)方式，既支持延遲加載，也支持高并發(fā)，實(shí)現(xiàn)起來(lái)也比雙重檢測(cè)簡(jiǎn)單。

public class StaticInnerClass {private AtomicLong id = new AtomicLong(0);private StaticInnerClass() {}/*** 靜態(tài)內(nèi)部類* SingletonHolder 是一個(gè)靜態(tài)內(nèi)部類，當(dāng)外部類 IdGenerator 被加載的時(shí)候，并不會(huì)創(chuàng)建 SingletonHolder 實(shí)例對(duì)象。* 只有當(dāng)調(diào)用 getInstance() 方法時(shí)，SingletonHolder 才會(huì)被加載，這個(gè)時(shí)候才會(huì)創(chuàng)建 instance。* instance 的唯一性、創(chuàng)建過(guò)程的線程安全性，都由 JVM 來(lái)保證。所以，這種實(shí)現(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 枚舉

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

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

四、總結(jié)

4.1 單例存在哪些問(wèn)題？

1. 單例對(duì) OOP 特性的支持不友好

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

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

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

3. 單例對(duì)代碼的擴(kuò)展性不友好

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

4. 單例對(duì)代碼的可測(cè)試性不友好

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

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

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

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

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

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