執行緒與鎖：從 CPU 快取到虛擬執行緒

並發之所以難，是因為有三種完全不同的問題，而它們的解法也不同。先把三種問題分清楚，後面所有工具（volatile、synchronized、CAS）才知道各自在解哪一個。

問題一：原子性 —— i++ 其實是三條指令

count++  編譯後大致是：

  ① 讀取 count 的值到暫存器      (getfield)
  ② 暫存器的值 +1               (iadd)
  ③ 寫回 count                  (putfield)

執行緒 A 讀到 5  ─┐
執行緒 B 讀到 5  ─┤  兩邊都算出 6
執行緒 A 寫回 6  ─┤
執行緒 B 寫回 6  ─┘  → 加了兩次，結果只加了 1

這叫競態條件（Race Condition）。中間任何一步被打斷，結果就錯了。

問題二：可見性 —— 你改了，別人看不到

private boolean running = true;

// 執行緒 A
while (running) { /* 幹活 */ }

// 執行緒 B
running = false;   // A 可能永遠看不到這個改動

B 明明已經改成 false，A 卻繼續跑。而且這個問題在單核機器或開發環境很難重現，上了多核正式環境才出事。原因在下一張卡。

問題三：有序性 —— 程式碼的執行順序跟你寫的不一樣

編譯器和 CPU 都會為了效能重新排列指令順序。只要「在單一執行緒看起來結果一樣」（as-if-serial），它們就可以自由重排。

// 你寫的
instance = new Singleton();

// 實際可能的順序
① 配置記憶體
③ 把 instance 指向那塊記憶體   ← 重排到前面了
② 執行建構子初始化

→ 另一條執行緒可能拿到「還沒初始化完成」的物件

「為什麼 B 改了 A 看不到」——這件事跟 Java 沒什麼關係，是現代 CPU 的必然結果。

起點：記憶體太慢了

回想 ch01 講磁碟時的同一個邏輯，只是換了一層：

• CPU 暫存器：< 1 個時脈週期
• L1 快取：約 4 個週期
• L3 快取：約 40 個週期
• 主記憶體：約 200 個週期

如果每次讀寫變數都要去主記憶體，CPU 大部分時間都在等。所以每個核心都有自己的 L1／L2 快取。

問題就出在「自己的」

核心 0                        核心 1
┌──────────┐                 ┌──────────┐
│ L1 快取   │                 │ L1 快取   │
│ running  │                 │ running  │
│  = true  │                 │  = true  │
└────┬─────┘                 └────┬─────┘
     └──────────┬─────────────────┘
           主記憶體  running = true

核心 1 寫入 running = false
  → 先進「store buffer」，之後才寫回快取／主記憶體
  → 核心 0 的 L1 裡還是 true
  → 核心 0 上的執行緒繼續看到 true

JMM：Java 記憶體模型在做什麼

硬體的快取一致性協定（MESI）在各家 CPU 上行為不同。Java 要「一次編譯到處執行」，所以定義了一層抽象：Java Memory Model 規定「什麼情況下，一個執行緒的寫入必須讓另一個執行緒看得到」。

happens-before：唯一需要記住的規則

如果操作 A happens-before 操作 B，那麼 A 的結果對 B 一定可見。幾條實用的規則：

• 程式順序規則：同一條執行緒內，前面的操作 happens-before 後面的
• volatile 規則：對 volatile 變數的寫 happens-before 後續對它的讀
• 鎖規則：unlock happens-before 後續對同一把鎖的 lock
• 傳遞性：A hb B、B hb C，則 A hb C

它做的兩件事

1. 可見性——寫入時強制刷到主記憶體，讀取時強制從主記憶體讀（不用自己的快取）
2. 禁止指令重排——在讀寫前後插入記憶體屏障（memory barrier）

它不做的那件事：原子性

private volatile int count = 0;

count++;   // ❌ 依然是錯的！

volatile 保證你讀到的是最新值，但 count++ 的「讀→加→寫」三步之間仍然可能被打斷。volatile 讓每一步都看得到最新值，但沒有讓三步變成一步。

正確用法一：狀態旗標（volatile 的經典場景）

private volatile boolean running = true;

public void stop() { running = false; }        // 單純的寫，不依賴舊值
public void run()  { while (running) { ... } } // 單純的讀

關鍵是寫入的值不依賴目前的值——這樣就沒有原子性問題，只剩可見性問題，正好是 volatile 的守備範圍。

正確用法二：雙重檢查鎖（DCL）

public class Singleton {
    private static volatile Singleton instance;   // ← volatile 不能省

    public static Singleton getInstance() {
        if (instance == null) {                    // 第一次檢查（不加鎖，快）
            synchronized (Singleton.class) {
                if (instance == null) {            // 第二次檢查（加鎖後再確認）
                    instance = new Singleton();
                }
            }
        }
        return instance;
    }
}

很多人對 synchronized 的印象還停留在「很重、要避免」。那是 JDK 6 以前的事。

鎖資訊存在物件頭裡

每個 Java 物件的物件頭（Object Header）有一塊 Mark Word，記錄鎖狀態、持有者、雜湊碼、GC 年齡（就是 ch04 說的晉升年齡）。鎖不是額外的物件，就存在物件自己身上。

鎖升級：只升不降

1. 無鎖
2. 偏向鎖（Biased）——如果從頭到尾只有一條執行緒進來過，在 Mark Word 記下它的 ID，之後那條執行緒進出幾乎零成本。
   （JDK 15 起預設關閉、JDK 18 移除——因為現代應用的執行緒競爭普遍，維護偏向鎖撤銷的成本反而高於收益。）
3. 輕量級鎖（Lightweight）——有第二條執行緒來競爭時升級。用 CAS 自旋：不掛起，原地轉幾圈等對方放開。適合持鎖時間很短的場景（省下執行緒切換的成本）。
4. 重量級鎖（Heavyweight）——自旋幾次還拿不到就升級。執行緒真的被掛起，要經過作業系統的排程器，需要使用者態／核心態切換，成本高。

synchronized vs ReentrantLock

ReentrantLock 不是「比較快的 synchronized」，它是功能比較多的鎖：

• 可以設超時：tryLock(3, TimeUnit.SECONDS) —— 拿不到就放棄，這是打破死鎖最實用的工具
• 可以中斷：lockInterruptibly()
• 可以是公平鎖：先到先得（但吞吐量較差，通常不用）
• 多個條件變數：newCondition()，可以精準喚醒某一群等待者

// ReentrantLock 一定要用 try-finally，否則例外時鎖不會釋放
lock.lock();
try {
    // 臨界區
} finally {
    lock.unlock();   // ← 忘了寫就是永久死鎖
}

鎖的本質是「悲觀」：假設一定會衝突，所以先擋住別人。CAS 是樂觀的：先做，做完再檢查有沒有被別人插隊，有的話重試。

CAS（Compare-And-Swap）

compareAndSet(expectedValue, newValue)

「如果現在的值還是 expectedValue，就改成 newValue；
  否則什麼都不做，回傳 false（代表被別人改過了）」

這整個「比較並交換」的動作由 CPU 指令保證是原子的（x86 的 CMPXCHG）

// AtomicInteger.incrementAndGet() 的核心邏輯
int prev, next;
do {
    prev = get();
    next = prev + 1;
} while (!compareAndSet(prev, next));   // 失敗就重試

ABA 問題

執行緒 A 讀到值 = 1
執行緒 B 把它改成 2，然後又改回 1
執行緒 A 執行 CAS(1, 3)  →  成功了！

但中間其實發生過事情——對某些場景（例如無鎖鏈結串列）這會出錯

解法：AtomicStampedReference，除了值還帶一個版本號，比對「值 + 版本」而不只是值。大多數業務場景不會遇到 ABA（只在意最終數值時無所謂），但寫無鎖資料結構時必須處理。

CAS 的代價：高競爭時自旋很浪費

失敗就重試，代表競爭越激烈、白跑的次數越多、CPU 燒得越兇。這是 CAS 跟鎖的根本取捨：

• 低競爭：CAS 完勝（沒有執行緒切換成本）
• 高競爭：鎖反而更好（掛起等待不燒 CPU）

LongAdder：高競爭下的解法

AtomicLong：所有執行緒搶同一個變數  →  高競爭時大量 CAS 失敗

LongAdder：拆成多個 Cell，每條執行緒各加各的
           要讀總和時才把所有 Cell 加起來
           → 把競爭「分散」掉

執行緒池是實務上最常用、也最常設錯的並發工具。它有七個參數，但真正決定行為的是任務提交時的判斷順序。

提交一個任務時，實際發生的事

① 目前執行緒數 < corePoolSize ？
   → 是：直接開一條新執行緒來跑（就算有閒著的也開）

② 否 → 丟進 workQueue 排隊

③ 佇列滿了 ？
   → 是：再開新執行緒，直到 maximumPoolSize

④ 執行緒數已達 maximumPoolSize 且佇列還是滿的 ？
   → 執行 拒絕策略（RejectedExecutionHandler）

為什麼不要用 Executors 的工廠方法

Executors.newFixedThreadPool(10)
  → 用無界 LinkedBlockingQueue  →  任務堆積到 OOM

Executors.newCachedThreadPool()
  → maximumPoolSize = Integer.MAX_VALUE  →  執行緒開到 OOM

Executors.newSingleThreadExecutor()
  → 同樣是無界佇列

正確做法：自己 new ThreadPoolExecutor，明確指定每個參數。

new ThreadPoolExecutor(
    8,                                  // corePoolSize
    16,                                 // maximumPoolSize
    60L, TimeUnit.SECONDS,              // 非核心執行緒的閒置存活時間
    new ArrayBlockingQueue<>(200),      // ← 有界！
    new ThreadFactoryBuilder()
        .setNameFormat("order-worker-%d").build(),   // ← 命名，出事時 jstack 看得懂
    new ThreadPoolExecutor.CallerRunsPolicy()        // 拒絕策略
);

四種拒絕策略

• AbortPolicy（預設）——丟 RejectedExecutionException。對線上服務通常是對的：快速失敗，讓上游知道。
• CallerRunsPolicy——由呼叫者自己執行。天然的反壓（back-pressure）：提交任務的執行緒被佔住，就沒空再提交，流量自然減緩。
• DiscardPolicy——默默丟掉。危險，任務憑空消失且無感。
• DiscardOldestPolicy——丟掉佇列裡最舊的。同樣危險。

池大小怎麼估

• CPU 密集（純運算）：核心數 + 1。開更多只會增加切換成本。
• I/O 密集（等資料庫、等 API）：核心數 × (1 + 等待時間/計算時間)。等待佔比越高，可以開越多。

死鎖的四個必要條件（缺一不可）

1. 互斥：資源同時只能被一個執行緒持有
2. 持有並等待：拿著 A 的同時去要 B
3. 不可剝奪：不能強制搶走別人手上的鎖
4. 循環等待：A 等 B、B 等 A

打破任何一個就不會死鎖——實務上最容易打破的是第 4 個（統一鎖順序）和第 2 個（tryLock 加超時）。

典型的循環等待

// 轉帳：A 轉給 B，同時 B 轉給 A
synchronized (accountA) {
    synchronized (accountB) { ... }     // 執行緒 1
}

synchronized (accountB) {
    synchronized (accountA) { ... }     // 執行緒 2  ← 順序相反
}

修法：統一鎖順序——例如永遠先鎖 ID 較小的帳戶，循環就不可能形成。

徵狀與診斷

• 徵狀：某些請求永遠不返回（不是變慢，是完全卡住）；執行緒數持續上升；CPU 使用率很低（大家都在等，沒人在跑）

# 抓執行緒堆疊
jstack <pid> > thread.txt

# JVM 會自動偵測並印出
"Found one Java-level deadlock:"
"Thread-1" waiting to lock monitor 0x... which is held by "Thread-2"
"Thread-2" waiting to lock monitor 0x... which is held by "Thread-1"

更陰險的變體：執行緒池自己把自己鎖死

ExecutorService pool = Executors.newFixedThreadPool(1);

pool.submit(() -> {
    // 父任務：提交一個子任務，然後等它完成
    Future<String> child = pool.submit(() -> "done");
    return child.get();     // ← 永遠等不到
});

1. 父任務佔用了唯一的那條執行緒
2. 子任務被丟進佇列，但沒有執行緒可以執行它
3. 父任務在等子任務，子任務在等執行緒——完美的死鎖

JDK 21 正式推出的虛擬執行緒（Virtual Threads），改變的是「執行緒是稀缺資源」這個前提。

平台執行緒為什麼稀缺

• 每條對應一個作業系統執行緒
• 預設堆疊 512KB～1MB（ch04 講過，這塊不受 -Xmx 管）
• 建立、銷毀、切換都要經過核心排程器
• 幾千條就是實務上限

所以才需要執行緒池——因為執行緒太貴，必須重複使用。

虛擬執行緒做了什麼

虛擬執行緒由 JVM 排程，掛在少量「載體執行緒」（carrier thread）上跑。

關鍵：當虛擬執行緒遇到阻塞 I/O 時
  → JVM 把它的堆疊「搬到 heap 上」，釋放載體執行緒
  → 載體執行緒立刻去跑別的虛擬執行緒
  → I/O 完成後，虛擬執行緒再被掛回某條載體執行緒繼續

結果：阻塞的是虛擬執行緒，不是作業系統執行緒

• 建立成本極低，可以開幾百萬條
• 寫的還是同步阻塞的程式碼（不用改成 reactive 那種回呼地獄）
• 不需要池化——用 Executors.newVirtualThreadPerTaskExecutor()，每個任務一條

陷阱一：釘住（Pinning）

陷阱二：以為它能加速 CPU 密集的工作

不能。虛擬執行緒省下的是「等待時佔住 OS 執行緒」的浪費。如果你的任務是純運算，它從頭到尾都在用 CPU，沒有等待可以省——反而多了排程開銷。CPU 密集請繼續用固定大小的平台執行緒池。

對連線池的影響（重點）

寫得出正確的並發程式碼是一回事，需不需要寫是另一回事。實務上大多數業務程式碼根本不該出現鎖。

優先順序：能不用鎖就不用

1. 無共享狀態——把可變狀態留在方法區域變數裡。Spring 的 @Service 是單例，成員變數放可變狀態就是 bug，這是最常見的並發錯誤來源。
2. 不可變物件——欄位全部 final，天生執行緒安全，不需要任何同步。
3. 併發容器——ConcurrentHashMap、CopyOnWriteArrayList、BlockingQueue。它們內部已經處理好，而且比你自己加鎖快。
4. 原子類——AtomicInteger、LongAdder。
5. 鎖——以上都不行時才用，而且盡量縮小範圍。

最常見的致命誤用：多實例部署下用 JVM 鎖

@Service
public class OrderService {
    // ❌ 這把鎖只在「這個 JVM 內」有效
    private final Object lock = new Object();

    public void createOrder(String userId) {
        synchronized (lock) {
            if (orderRepo.existsByUserId(userId)) return;   // 檢查
            orderRepo.save(new Order(userId));              // 建立
        }
    }
}

一句話收尾