重學 Java 設計模式：實戰單例模式

重學 Java 設計模式：實戰單例模式

一、前言

5個建立型模式的最後一個

在設計模式中按照不同的處理方式共包含三大類；建立型模式、結構型模式和行為模式，其中建立型模式目前已經介紹了其中的四個；工廠方法模式、抽象工廠模式、生成器模式和原型模式，除此之外還有最後一個單例模式。

掌握了的知識才是自己的

在本次編寫的重學 Java 設計模式的編寫中盡可能多的用各種場景案例還介紹設計的使用，包括我們已經使用過的場景；各種類型獎品發放、多套Redis緩存叢集更新、裝修公司報價清單和百份考卷題目與答案亂序，通過這些場景案例的實踐感受設計模式的思想。但這些場景都是作者通過經驗分離出來的，還并不是讀者的知識，是以你如果希望可以融會貫通的掌握那麼一定要親力親為的操作，事必躬親的完成。

書不是看的是用的

在這裡還是想強調一下學習方法，總有很多小夥伴對學習知識有疑惑，明明看了、看的時候也懂了，但到了實際使用的時候卻用不上。或者有時候在想是不要是有更加生動的漫畫或者什麼對比會好些，當然這些方式可能會加快一個新人對知識的了解速度。但隻要你把學習視訊當電影看、學習書籍當故事看，就很難掌握這項技術棧。隻有你把它用起來，逐字逐句的深挖，一點點的探求，把各項遇到的盲點全部掃清，才能讓你真的掌握這項技能。

二、開發環境

JDK 1.8

Idea + Maven

涉及工程1個，可以通過關注公衆号：bugstack蟲洞棧，回複源碼下載下傳擷取(打開擷取的連結，找到序号18)

三、單例模式介紹

單例模式可以說是整個設計中最簡單的模式之一，而且這種方式即使在沒有看設計模式相關資料也會常用在編碼開發中。

因為在程式設計開發中經常會遇到這樣一種場景，那就是需要保證一個類隻有一個執行個體哪怕多線程同時通路，并需要提供一個全局通路此執行個體的點。

綜上以及我們平常的開發中，可以總結一條經驗，單例模式主要解決的是，一個全局使用的類頻繁的建立和消費，進而提升提升整體的代碼的性能。

四、案例場景

本章節的技術所出現的場景非常簡單也是我們日常開發所能見到的，例如；

資料庫的連接配接池不會反複建立

spring中一個單例模式bean的生成和使用

在我們平常的代碼中需要設定全局的的一些屬性儲存

在我們的日常開發中大緻上會出現如上這些場景中使用到單例模式，雖然單例模式并不複雜但是使用面卻比較廣。

五、7種單例模式實作

單例模式的實作方式比較多，主要在實作上是否支援懶漢模式、是否線程安全中運用各項技巧。當然也有一些場景不需要考慮懶加載也就是懶漢模式的情況，會直接使用static靜态類或屬性和方法的方式進行處理，供外部調用。

那麼接下來我們就通過實作不同方式的實作進行講解單例模式。

1. 靜态類使用
2. class Singleton_00 {

public static Map<String,String> cache = new ConcurrentHashMap<String, String>();
           

}

以上這種方式在我們平常的業務開發中非常場常見，這樣靜态類的方式可以在第一次運作的時候直接初始化Map類，同時這裡我們也不需要到延遲加載在使用。

在不需要維持任何狀态下，僅僅用于全局通路，這個使用使用靜态類的方式更加友善。

但如果需要被繼承以及需要維持一些特定狀态的情況下，就适合使用單例模式。

1. 懶漢模式(線程不安全)
2. class Singleton_01 {

private static Singleton_01 instance;

private Singleton_01() {
}

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

單例模式有一個特點就是不允許外部直接建立，也就是new Singleton_01()，是以這裡在預設的構造函數上添加了私有屬性 private。

目前此種方式的單例确實滿足了懶加載，但是如果有多個通路者同時去擷取對象執行個體你可以想象成一堆人在搶廁所，就會造成多個同樣的執行個體并存，進而沒有達到單例的要求。

1. 懶漢模式(線程安全)
2. class Singleton_02 {

private static Singleton_02 instance;

private Singleton_02() {
}

public static synchronized Singleton_02 getInstance(){
    if (null != instance) return instance;
    return new Singleton_02();
}
           

此種模式雖然是安全的，但由于把鎖加到方法上後，所有的通路都因需要鎖占用導緻資源的浪費。如果不是特殊情況下，不建議此種方式實作單例模式。

1. 餓漢模式(線程安全)
2. class Singleton_03 {

private static Singleton_03 instance = new Singleton_03();

private Singleton_03() {
}

public static Singleton_03 getInstance() {
    return instance;
}
           

此種方式與我們開頭的第一個執行個體化Map基本一緻，在程式啟動的時候直接運作加載，後續有外部需要使用的時候擷取即可。

但此種方式并不是懶加載，也就是說無論你程式中是否用到這樣的類都會在程式啟動之初進行建立。

那麼這種方式導緻的問題就像你下載下傳個遊戲軟體，可能你遊戲地圖還沒有打開呢，但是程式已經将這些地圖全部執行個體化。到你手機上最明顯體驗就一開遊戲記憶體滿了，手機卡了，需要換了。

1. 使用類的内部類(線程安全)
2. class Singleton_04 {

private static class SingletonHolder {
    private static Singleton_04 instance = new Singleton_04();
}

private Singleton_04() {
}

public static Singleton_04 getInstance() {
    return SingletonHolder.instance;
}
           

使用類的靜态内部類實作的單例模式，既保證了線程安全有保證了懶加載，同時不會因為加鎖的方式耗費性能。

這主要是因為JVM虛拟機可以保證多線程并發通路的正确性，也就是一個類的構造方法在多線程環境下可以被正确的加載。

此種方式也是非常推薦使用的一種單例模式

1. 雙重鎖校驗(線程安全)
2. class Singleton_05 {

private volatile static Singleton_05 instance;

private Singleton_05() {
}

public static Singleton_05 getInstance(){
   if(null != instance) return instance;
   synchronized (Singleton_05.class){
       if (null == instance){
           instance = new Singleton_05();
       }
   }
   return instance;
}
           

雙重鎖的方式是方法級鎖的優化，減少了部分擷取執行個體的耗時。

同時這種方式也滿足了懶加載。

volatile關鍵字會強制的保證線程的可見性，而不加這個關鍵字，JVM也會盡力去保證可見性，但如果CPU一直處于繁忙狀态就不确定了。

1. CAS「AtomicReference」(線程安全)
2. class Singleton_06 {

private static final AtomicReference<Singleton_06> INSTANCE = new AtomicReference<Singleton_06>();

private static Singleton_06 instance;

private Singleton_06() {
}

public static final Singleton_06 getInstance() {
    for (; ; ) {
        Singleton_06 instance = INSTANCE.get();
        if (null != instance) return instance;
        INSTANCE.compareAndSet(null, new Singleton_06());
        return INSTANCE.get();
    }
}

public static void main(String[] args) {
    System.out.println(Singleton_06.getInstance()); // org.itstack.demo.design.Singleton_06@2b193f2d
    System.out.println(Singleton_06.getInstance()); // org.itstack.demo.design.Singleton_06@2b193f2d
}
           

java并發庫提供了很多原子類來支援并發通路的資料安全性；AtomicInteger、AtomicBoolean、AtomicLong、AtomicReference。

AtomicReference 可以封裝引用一個V執行個體，支援并發通路如上的單例方式就是使用了這樣的一個特點。

使用CAS的好處就是不需要使用傳統的加鎖方式保證線程安全，而是依賴于CAS的忙等算法，依賴于底層硬體的實作，來保證線程安全。相對于其他鎖的實作沒有線程的切換和阻塞也就沒有了額外的開銷，并且可以支援較大的并發性。

當然CAS也有一個缺點就是忙等，如果一直沒有擷取到将會處于死循環中。

1. Effective Java作者推薦的枚舉單例(線程安全)
2. enum Singleton_07 {

INSTANCE;
public void test(){
    System.out.println("hi~");
}
           

約書亞·布洛克（英語：Joshua J. Bloch，1961年8月28日－），美國著名程式員。他為Java平台設計并實作了許多的功能，曾擔任Google的首席Java架構師（Chief Java Architect）。

Effective Java 作者推薦使用枚舉的方式解決單例模式，此種方式可能是平時最少用到的。

這種方式解決了最主要的；線程安全、自由串行化、單一執行個體。

調用方式

@Test

public void test() {

Singleton_07.INSTANCE.test();           

這種寫法在功能上與共有域方法相近，但是它更簡潔，無償地提供了串行化機制，絕對防止對此執行個體化，即使是在面對複雜的串行化或者反射攻擊的時候。雖然這中方法還沒有廣泛采用，但是單元素的枚舉類型已經成為實作Singleton的最佳方法。

但也要知道此種方式在存在繼承場景下是不可用的。

六、總結

雖然隻是一個很平常的單例模式，但在各種的實作上真的可以看到java的基本功的展現，這裡包括了；懶漢、餓漢、線程是否安全、靜态類、内部類、加鎖、串行化等等。

在平時的開發中如果可以確定此類是全局可用不需要做懶加載，那麼直接建立并給外部調用即可。但如果是很多的類，有些需要在使用者觸發一定的條件後(遊戲關卡)才顯示，那麼一定要用懶加載。線程的安全上可以按需選擇。

建議在學習的過程中一定要加以實踐，否則很難完完整整的掌握一整套的知識體系。例如案例中的出現的Effective Java一書也非常建議大家閱讀。另外推薦下這位大神的Github：

https://github.com/jbloch

七、推薦閱讀

重學 Java 設計模式：實戰原型模式-模拟考試試卷亂序題目和答案

Java開發架構篇：初識領域驅動設計DDD落地

Java開發架構篇：DDD模型領域層決策規則樹服務設計

Java開發架構篇：領域驅動設計架構基于SpringCloud搭建微服務

源碼分析(面試常問題目) | Mybatis接口沒有實作類為什麼可以執行增删改查

講道理，隻要你是一個愛折騰的程式員，畢業找工作真的不需要再花錢教育訓練！

作者：小傅哥

原文位址

https://www.cnblogs.com/xiaofuge/p/13023749.html