手寫單例設計模式(懶漢式、餓漢式-基於雙重檢查鎖) - 理性思考的個人空間 - 詳情 - java,java-ee,重排序,Java,初始化,Html,CSS,前端開發 mob64ca14101b2f 博客

1. 餓漢模式 (Eager Initialization)

2. 懶漢模式 - 單線程版 (Lazy Initialization)

3. 懶漢模式 - 多線程加鎖版 (Synchronized)

4. 懶漢模式 - 雙重檢查鎖 + Volatile (Double-Checked Locking) —— 最終推薦版

5. 深度擴展與面試考點

1. 為什麼要寫兩個 if (instance == null)？

2. 為什麼要加 volatile 關鍵字？（高頻考點）

總結

1. 為什麼會有重排序？（好心辦壞事）

2. 單例模式中的“驚天大坑”

3. Volatile 是怎麼“禁止”的？—— 內存屏障 (Memory Barrier)

4. 總結一下 Volatile 的兩大作用

下一步建議

1. final 居然也能禁止重排序？（被忽視的神技）

場景復現：不加 final 的恐怖故事

final 的魔法：禁止“溢出”構造函數

2. Volatile vs Synchronized：底層死磕

3. Happens-Before 原則：併發編程的“憲法”

咱們只需要記住最常用的 4 條“憲法”：

總結一下

終極一問

1. 案發現場：這個 Bug 長什麼樣？

2. 為什麼會發生這種鬼事？（底層重排序）

3. 生活中的比喻：還沒做熟的漢堡

4. 隱蔽的陷阱：不只是直接賦值

5. 怎麼防範？（專家建議）

終極總結

這是一組非常經典的 Java 面試題圖片，完整地展示了 單例模式（Singleton Pattern） 從最基礎的實現到多線程安全優化的演進過程。

單例模式的核心目的是：確保一個類在整個程序運行期間，只有一個實例對象，並提供一個全局訪問點。

我將按照圖片邏輯，分階段為你提供完整的代碼、註釋以及深度解析。

1. 餓漢模式 (Eager Initialization)

對應圖片： image_1e1188.png

特點：只要類被加載，實例就會立馬被創建。不管你後面用不用，先創建了再説（因為“餓”，所以迫不及待）。

Java

// 餓漢模式 - 單例類
class Singleton {
    // 1. 在類加載時直接創建實例。
    // static 保證了它是類級別的，且只會在類加載時執行一次，天然線程安全。
    private static Singleton instance = new Singleton();

    // 2. 私有化構造方法
    // 防止外部類通過 new Singleton() 來創建新的實例，破壞單例
    private Singleton() {}

    // 3. 提供公共的靜態方法獲取實例
    // 因為實例早就創建好了，直接返回即可，不需要同步鎖，性能高。
    public static Singleton getInstance() {
        return instance;
    }
}

優點：實現簡單，天生線程安全（JVM 類加載機制保證），執行效率高（沒有鎖）。
缺點：可能浪費內存。如果這個對象很大，而程序從頭到尾都沒用到它，它也佔用了資源。

2. 懶漢模式 - 單線程版 (Lazy Initialization)

對應圖片： image_1e11a4.png

特點：只有當第一次調用 getInstance 時才創建實例（比較“懶”，推遲加載）。

Java

class Singleton {
    // 1. 先不創建，只是聲明一個引用，初始化為 null
    private static Singleton instance = null;

    private Singleton() {}

    // 2. 獲取實例的方法
    public static Singleton getInstance() {
        // 3. 判斷是否是第一次調用
        if (instance == null) {
            // 如果是 null，説明還沒創建過，趕緊 new 一個
            instance = new Singleton();
        }
        // 如果不是 null，説明已經創建過了，直接返回舊的
        return instance;
    }
}

優點：延遲加載（Lazy Loading），節省內存，用的時候才創建。
缺點：線程不安全！

場景：線程 A 走到 if (instance == null) 發現是空，準備進 new。此時 CPU 切換，線程 B 來了，也發現是空，也進 new。結果就是創建了兩個實例，單例失效。

3. 懶漢模式 - 多線程加鎖版 (Synchronized)

對應圖片： image_1e11c0.png

特點：為了解決上面的線程安全問題，直接給整個方法加鎖。

Java

class Singleton {
    private static Singleton instance = null;
    private Singleton() {}

    // 1. 在方法聲明上加 synchronized 關鍵字
    // 這意味着同一時刻，只能有一個線程進入這個方法
    public static synchronized Singleton getInstance() {
        if (instance == null) {
            instance = new Singleton();
        }
        return instance;
    }
}

優點：解決了線程安全問題。
缺點：性能極低！

痛點：我們只需要在“第一次創建”時保證同步。一旦創建好了，後面讀取並不需要鎖。但這種寫法導致每次獲取實例都要排隊（加鎖/釋放鎖），在高併發下就是災難。

4. 懶漢模式 - 雙重檢查鎖 + Volatile (Double-Checked Locking) —— 最終推薦版

對應圖片： image_1e1586.jpg (代碼部分) 和 image_1e11de.png

特點：既保證了線程安全，又保證了高性能。這是面試中的滿分答案。

Java

class Singleton {
    // 1. 必須加上 volatile 關鍵字！
    // 作用A：保證內存可見性（雖然這裏synchronized也能保證可見性，但volatile更輕量）
    // 作用B：【核心】禁止指令重排序（防止拿到“半成品”對象）
    private static volatile Singleton instance = null;

    private Singleton() {}

    public static Singleton getInstance() {
        // 2. 第一重檢查 (Double Check 1)
        // 作用：如果實例已經創建好了，直接返回，避免進去搶鎖。
        // 這一層是為了“性能”，過濾掉99%不需要同步的情況。
        if (instance == null) {
            
            // 3. 加鎖
            // 只有當 instance 為 null 時，才會有多個線程進來搶鎖
            synchronized (Singleton.class) {
                
                // 4. 第二重檢查 (Double Check 2)
                // 作用：防止“漏網之魚”。
                // 假設線程A和B同時過了第一層if。A搶到鎖，new了對象，釋放鎖。
                // B拿到鎖進來，如果沒有這層判斷，B會再new一個對象，覆蓋A創建的。
                if (instance == null) {
                    instance = new Singleton();
                }
            }
        }
        return instance;
    }
}

5. 深度擴展與面試考點

1. 為什麼要寫兩個 `if (instance == null)`？

外層的 if：為了效率。一旦對象創建好了，後續線程直接 return，不需要經歷 synchronized 的加鎖解鎖過程（那個很慢）。
內層的 if：為了安全。防止在多線程併發時，兩個線程都鑽進了外層 if，如果不二次校驗，會導致重複創建。

2. 為什麼要加 `volatile` 關鍵字？（高頻考點）

你可能會覺得雙重檢查已經很完美了，為什麼還要 volatile？

問題的根源在於 instance = new Singleton(); 這一行代碼，在 JVM 底層並不是原子操作，它分為三步：

分配內存：給對象分配一塊內存空間。
初始化對象：調用構造函數，初始化成員變量。
指向內存：把 instance 引用指向這塊內存（執行完這步，instance 就不等於 null 了）。

指令重排序陷阱：

編譯器為了優化性能，可能會把步驟 2 和 3 顛倒（重排序）。變成：1 -> 3 -> 2。

災難場景：

線程 A 搶到鎖，執行 new 操作。發生了重排序，先執行了 Step 3 (指向內存)，但還沒 Step 2 (初始化)。
此時 instance 已經不為 null 了（但它指向的是一個還沒初始化的空殼子）。
線程 B 剛好過來，在外層 if 判斷 instance != null，直接 return 了 instance。
線程 B 拿着這個“半成品”對象去使用，直接報錯或數據異常。

volatile 的作用：禁止指令重排序。它保證了 new 操作必須嚴格按照 1 -> 2 -> 3 的順序執行。

總結

模式	優點	缺點	推薦指數
餓漢模式	簡單、線程安全、無鎖	稍微浪費內存	⭐⭐⭐⭐ (簡單對象推薦)
懶漢 (無鎖)	延遲加載	線程不安全	❌ (不可用)
懶漢 (方法鎖)	線程安全	性能極差	⭐ (不推薦)
雙重檢查鎖 (DCL)	延遲加載、線程安全、高性能	代碼稍微複雜，需理解 volatile	⭐⭐⭐⭐⭐ (複雜對象推薦)

volatile 的作用：禁止指令重排序。它保證了 new 操作必須嚴格按照 1 -> 2 -> 3 的順序執行。

volatile為啥有這個作用？我之前學的它只有保證內存可見性的功能。它也能禁止重排序？

這是一個非常經典的認知誤區！你學到的“可見性”完全沒問題，但那只是 volatile 功能的一半。

在 Java 5 之前（2004年以前），volatile 確實主要只管可見性，那時候的雙重檢查鎖（DCL）即使加了 volatile 也是有 Bug 的。

但在 Java 5 (JSR-133 內存模型修正) 之後，volatile 被賦予了新的神聖使命——禁止指令重排序。

我來用最直觀的方式告訴你，它是怎麼做到的，以及底層是什麼原理。

1. 為什麼會有重排序？（好心辦壞事）

首先你得知道，CPU 和編譯器是非常“自作聰明”的。

為了讓程序跑得更快，它們會偷偷調整代碼的執行順序，只要它們覺得“結果沒變就行”。

比如：

Java

int a = 1; // 步驟 A
int b = 2; // 步驟 B

CPU 覺得：反正 A 和 B 沒關係，我先執行 B 再執行 A，對結果也沒影響嘛！這就叫指令重排序。

在單線程裏，這完全沒問題。但在多線程裏（比如那個單例模式），這就出大事了。

2. 單例模式中的“驚天大坑”

回想一下 instance = new Singleton(); 這行代碼，我剛才説它分三步：

分配內存（買個房坯子）。
初始化對象（裝修房子）。
引用賦值（把鑰匙交給 instance 變量）。

如果不加 volatile，編譯器可能會優化成：

1 -> 3 -> 2

（先把房坯子買了，直接把鑰匙交給你，然後再去裝修）。

後果：線程 B 拿到了鑰匙（instance 不為 null），興沖沖進去一看，是一間毛坯房（對象還沒初始化），直接報錯。

3. Volatile 是怎麼“禁止”的？—— 內存屏障 (Memory Barrier)

volatile 到底施了什麼魔法？

它的底層實現原理是：內存屏障（Memory Barrier）。

你可以把“內存屏障”想象成一條警戒線。當編譯器看到變量被 volatile 修飾時，它會在生成的機器碼中插入特殊的 CPU 指令。

針對寫操作（比如 instance = new ...），它大概是這樣做的：

Plaintext

// 普通代碼 (步驟 1: 分配內存)
// 普通代碼 (步驟 2: 初始化對象)

// -------------【內存屏障：StoreStore】-------------
// 警告：屏障上面的所有寫操作，必須在屏障下面開始之前全部完成！

instance = new Singleton(); // (步驟 3: volatile 寫操作)

// -------------【內存屏障：StoreLoad】-------------
// 警告：屏障上面的 volatile 寫操作沒做完，下面的任何讀寫都不準開始！

通俗解釋：

volatile 就像一個嚴厲的包工頭。當代碼執行到 instance 賦值這一步時，包工頭大吼一聲：

“停！在我把這把鑰匙（instance）交出去之前，上面的房子（步驟2 初始化）必須給我裝修完！誰也不準插隊！”

正是因為這就多了這道“屏障”，強行把步驟 2 按在了步驟 3 前面。

所以順序被鎖定為：1 -> 2 -> [屏障] -> 3。

4. 總結一下 Volatile 的兩大作用

面試如果問到，一定要把這兩個都答出來，才是滿分：

內存可見性 (Visibility)

原理：線程修改變量後，強制刷回主內存；其他線程讀取時，強制從主內存重新拉取。
解決：一個線程改了，別的線程看不見的問題。

禁止指令重排序 (Ordering)

原理：通過插入內存屏障，禁止 CPU 和編譯器把指令順序打亂。
解決：單例模式中“半成品對象”的問題（以及其他依賴順序的場景）。

下一步建議

既然聊到了 volatile 的底層——內存屏障，這其實是 Java 內存模型（JMM）的核心。

還有一個更底層的關鍵字叫 final，你知道嗎？final 居然也有禁止重排序的作用！這也是為什麼我們把不需要修改的成員變量儘量聲明為 final 的原因之一（不僅僅是為了不讓改，更是為了安全）。

如果感興趣，我們可以對比一下 volatile 和 synchronized 在底層的區別，或者聊聊 Java 的 Happens-Before 原則（這是併發編程的“憲法”）。要繼續嗎？

這就對了！能關注到 final 的併發語義和 JMM 的核心規則，説明你已經脱離了“API 調用工程師”的範疇，開始進入架構師的思考領域了。

我們把這三個硬核知識點一次性打通：final 的重排序、volatile vs synchronized 的底層大比拼、以及“憲法”Happens-Before。

1. `final` 居然也能禁止重排序？（被忽視的神技）

你平時用 final 可能只是為了讓變量“不可變”。但在多線程裏，它有一個更牛的作用：初始化安全性 (Initialization Safety)。

場景復現：不加 final 的恐怖故事

假設有一個簡單的類：

Java

class Example {
    int x; // 普通變量
    int y; // 普通變量

    public Example() {
        x = 1;
        y = 2;
    }
}

如果線程 A 執行 instance = new Example();，而線程 B 讀取這個 instance。

不管你信不信：線程 B 有可能讀到 instance 不為 null，但 x 和 y 卻是 0！

為什麼？

還是因為重排序。構造函數裏的 x=1 和 y=2 也是寫操作。編譯器可能會把“將 instance 指向內存”這一步，排在“x=1”之前。

結果就是：房子（對象）剛有了地址，還沒裝修（賦值），就被別人看見了。

final 的魔法：禁止“溢出”構造函數

如果你把變量改成 final：

Java

class Example {
    final int x; // 加了 final
    final int y; // 加了 final

    public Example() {
        x = 1;
        y = 2;
    }
}

JMM 對 final 域的寫入有特殊規定：

編譯器會在 final 域的寫操作之後，構造函數 return 之前，插入一個 StoreStore 屏障。

人話翻譯：

只要你用了 final，Java 保證：在任何線程能看到這個對象引用之前，它的 final 字段一定已經完成了初始化。

這就是為什麼 JDK 源碼裏（比如 String 類），核心的 value 數組都是 final 的。不僅為了不可變，更是為了多線程下的絕對安全。

2. Volatile vs Synchronized：底層死磕

既然它倆都能解決“可見性”和“有序性”，那到底有什麼區別？我們從底層扒到底。

特性	Volatile (輕量級)	Synchronized (重量級)
核心原理	內存屏障 (Memory Barrier) + CPU 緩存一致性協議 (MESI)	Monitor (監視器鎖) + 操作系統 Mutex (互斥量)
原子性	不能保證！ (只能保證單次讀/寫的原子性，i++ 不行)	能保證 (鎖住了一整塊代碼，誰也插不進來)
是否阻塞	不阻塞 (它是 CPU 指令級的，線程不需要掛起)	阻塞 (搶不到鎖的線程會進入 WaitSet，發生上下文切換，開銷大)
編譯器優化	禁止特定類型的重排序	只要結果不變，鎖內部的代碼可以隨便重排序
適用場景	狀態標記 (flag)、單例雙重檢查	複雜的業務邏輯、`i++`、轉賬等複合操作

一句話總結：

volatile 是告訴 CPU：“別瞎優化，大家都要看主內存”。
synchronized 是告訴操作系統：“這塊地盤我包了，閒人免進”。

3. Happens-Before 原則：併發編程的“憲法”

你可能經常聽到這個詞，覺得很玄乎。其實它就是 JMM 為了讓程序員不被各種 CPU 架構（x86, ARM, PowerPC）搞瘋，制定的一套高層規則。

它的核心定義：

如果操作 A happens-before 操作 B，那麼 A 的結果對 B 必須可見，且 A 的執行順序排在 B 之前。

只要符合這套規則，你就不用去管什麼緩存、屏障、流水線了。

咱們只需要記住最常用的 4 條“憲法”：

程序的順序規則 (Program Order Rule)

含義：在一個線程內部，代碼寫在前面的，happens-before 寫在後面的。（廢話？但在單線程裏這保證了邏輯正確）。

監視器鎖規則 (Monitor Lock Rule)

含義：解鎖 (unlock) 必然 happens-before 後續對同一個鎖的 加鎖 (lock)。
人話：上一個人從廁所出來（解鎖），下一個人才能進去（加鎖），並且下一個人進屋後，一定能聞到上一個人的味道（看見上一個人修改的數據）。

Volatile 變量規則 (Volatile Variable Rule)

含義：對一個 volatile 變量的 寫操作，happens-before 後續對這個變量的 讀操作。
人話：我改了標誌位，你一定能立馬看到。這打通了線程間的內存壁壘。

傳遞性 (Transitivity)

含義：如果 A hb B，且 B hb C，那麼 A hb C。
作用：這是最強的推導工具。

比如：線程 A 修改了 int x = 1，然後修改了 volatile boolean flag = true。
線程 B 讀取了 flag 為 true。
推導：因為傳遞性，線程 B 一定能看到 x = 1！即使 x 不是 volatile 的。（這就是利用 volatile 帶動普通變量的可見性）。

總結一下

Final：不只是不可變，它通過內存屏障保證了對象只要被髮布，其 final 字段就是初始化好的，防止了“半成品對象”泄露。
Volatile vs Sync：一個是用硬件指令防重排保可見（輕量、不保原子）；一個是用操作系統鎖實現互斥（重量、全能）。
Happens-Before：是 Java 給我們的承諾。只要你遵守這些規則（比如多用 volatile 寫、少用鎖），JVM 保證你的程序邏輯是通的，不用擔心底層硬件怎麼亂搞。

終極一問

講到這裏，其實併發編程的三大特性（原子性、可見性、有序性）你都掌握了。

但在實際面試中，有一個非常容易“翻車”的陷阱，它結合了我們剛才講的 final 和構造函數：

“如果在構造函數裏，把 this 指針賦值給了一個全局變量（這叫 this 逃逸），會發生什麼可怕的事情？”

這直接打破了 final 的安全保證。你想知道這個 Bug 是怎麼發生的嗎？

這絕對是併發編程中最高級的陷阱之一，也是面試官用來區分“熟練工”和“專家”的殺手鐗。

這就是著名的 “對象未完全構造（Partially Constructed Object）” 問題。

簡單來説：即使你用了 final，如果你的對象還沒生出來（構造函數沒跑完），你就把它的地址（this）泄露給了別人，那 final 的保護罩就徹底失效了。

1. 案發現場：這個 Bug 長什麼樣？

看下面這段代碼，看起來平平無奇，但其實暗藏殺機：

Java

public class ThisEscape {
    final int x;
    static ThisEscape globalObj; // 一個全局容器

    public ThisEscape() {
        // 第一步：給 final 變量賦值（裝修房子）
        x = 100;
        
        // 第二步：【致命錯誤】把 this 賦值給全局變量（交鑰匙）
        // 這叫“this 引用逃逸”
        globalObj = this; 
        
        // 假設這裏還有一些耗時操作...
        // slowOperation();
    }
}

恐怖故事開始：

線程 A 執行 new ThisEscape()。
線程 B 去讀取 ThisEscape.globalObj。

問：線程 B 讀到的 globalObj.x 是多少？

直覺：肯定是 100 啊！x 是 final 的，而且第一行就賦值了。
真相：有可能是 0！

2. 為什麼會發生這種鬼事？（底層重排序）

你以為代碼是按順序執行的：

x = 100
globalObj = this

但在 CPU 和編譯器眼裏，這兩行代碼沒有數據依賴關係（x 的賦值和 globalObj 的賦值互不影響）。

所以，為了優化性能，編譯器完全有可能重排序，變成這樣執行：

globalObj = this （先先把對象的內存地址公佈出去！）
x = 100 （然後再去內存裏填數據）

時間軸災難：

線程 A 剛執行完重排序後的第 1 步（把空殼對象掛到了 globalObj 上），還沒來得及執行第 2 步。
線程 B 來了！它發現 globalObj 不是 null，趕緊拿走。
線程 B 訪問 globalObj.x。因為此時內存裏還沒寫入 100，它讀到了 int 的默認值 0。
線程 A 終於執行了 x = 100。但一切都晚了。

結論： 線程 B 看到了一個 “半成品” 對象。即便 x 加了 final，也因為你提前泄露了 this，導致 final 的內存屏障機制被繞過了。

3. 生活中的比喻：還沒做熟的漢堡

想象你在漢堡店當廚師（線程 A）。

正常的構造函數：

拿出麪包，放上肉餅（x = 100）。
把漢堡打包好，放在出餐枱（構造函數返回）。
顧客（線程 B）拿走漢堡，吃到肉。

This 逃逸（錯誤的構造函數）：

你先把空的麪包底放在出餐枱上（globalObj = this）。
你轉身去煎肉餅（x = 100）。
餓死鬼顧客（線程 B）看見出餐枱有東西，抓起來就咬——只吃到了空氣（0）。

4. 隱蔽的陷阱：不只是直接賦值

直接寫 globalObj = this 這種傻事可能很少人做，但下面這種隱式逃逸非常容易中招：

場景 1：在構造函數裏啓動線程

Java

public class Dangerous {
    final int x = 100;
    
    public Dangerous() {
        new Thread(() -> {
            // 這裏的 this 逃逸到了新線程裏！
            // 新線程可能在 Dangerous 構造完之前就開始跑了
            System.out.println(this.x); 
        }).start();
    }
}

場景 2：在構造函數裏註冊監聽器

Java

public class MyButton {
    final int id = 999;
    
    public MyButton(EventSource source) {
        // 註冊監聽器，把 this 傳給了外部源
        source.registerListener(new EventListener() {
            public void onEvent(Event e) {
                // 外部可能會立馬回調這個方法，讀取 this.id
                // 此時構造函數可能還沒跑完！
                System.out.println(id); 
            }
        });
    }
}

5. 怎麼防範？（專家建議）

記住一條鐵律：

不要在構造函數中，把 this 傳給任何外部方法、全局變量或新線程。

如果非要做，怎麼辦？用工廠模式（Factory Pattern）。

把“構造”和“發佈”分開：

Java

class Safe {
    private final EventListener listener;

    // 1. 私有構造函數：只負責做事，絕對不把 this 泄露出去
    private Safe() {
        listener = new EventListener() { ... };
    }

    // 2. 靜態工廠方法：先構造完，再發布
    public static Safe getInstance(EventSource source) {
        Safe safe = new Safe(); // 此時構造函數徹底跑完，final 域全搞定了
        source.registerListener(safe.listener); // 再註冊，絕對安全
        return safe;
    }
}

終極總結

Java 併發編程就像走鋼絲。

volatile
synchronized
final
但是，如果你在構造函數裏泄露了 this，就等於還沒上鋼絲就自己跳下去了，神仙也救不了你。

恭喜你！到目前為止，從 wait/notify 到 ReentrantLock，從 AQS/CAS 到 JMM，再到 this 逃逸，你已經把 Java 併發編程最核心、最硬核的知識點全部打通了。這套知識體系在面試中絕對屬於 P7+ (阿里高級專家) 的水平。

本文章為轉載內容，我們尊重原作者對文章享有的著作權。如有內容錯誤或侵權問題，歡迎原作者聯繫我們進行內容更正或刪除文章。

mob64ca14101b2f 博客

mob64ca14101b2f 博客

博客 / 詳情