Java 多線程同步深度實戰：從核心問題到 JUC 組件全景解析

多線程同步是 Java 併發編程的核心課題。本文從「為何需要同步」切入，剖析共享變量與執行順序兩大核心問題，演示多種解決策略，手寫線程池演練管控邏輯，並全面講解 JDK java.util.concurrent (JUC) 包中的核心組件應用，助你構建健壯、高效的併發系統。

一、 為何需要線程同步？

同步問題主要發生在「單對象、多線程」場景，核心癥結在於兩點：

1. 共享變量競態

多線程同時修改同一實例的實例變量（堆內存共享），導致數據競爭。例如兩線程同時累加 sum += i，預期各自得 5050，實際因交替覆蓋導致結果翻倍為 10100。

class MyRunner implements Runnable {
    public int sum = 0; // 共享變量
    public void run() {
        for (int i = 1; i <= 100; i++) sum += i;
        // ...
    }
}
// 兩線程共用同一 runner 實例 → 數據競爭

2. 執行順序不可控

多線程交替執行時，期望的原子操作序列（線程1完整執行步驟1-3，再輪到線程2）可能被打亂，導致業務邏輯錯誤。

二、 解決共享變量問題的三大策略

策略一：改為「多對象、多線程」—— 隔離狀態

每個線程使用獨立的 Runnable 實例，各自擁有獨立的 sum 變量，徹底消除共享。缺點：無法實現真正的數據共享協作，適用場景受限。

策略二：將「全局變量」降級為「局部變量」—— 線程封閉

將 sum 移入 run() 方法內部，成為線程私有的棧幀局部變量。優勢：無鎖、高性能、線程絕對安全。核心思想：無共享，無傷害。

策略三：使用 ThreadLocal —— 線程本地存儲

ThreadLocal 為每個線程維護獨立的變量副本，邏輯上「全局可見」，物理上「線程隔離」。適用於線程內多方法傳遞上下文（如事務 ID、數據庫連接、用戶會話）。

public ThreadLocal<Integer> tl = new ThreadLocal<>();
public void run() {
    tl.set(0); // 初始化
    int sum = tl.get() + i;
    tl.set(sum);
}

建議：優先考慮策略二（局部變量），其次策略三（ThreadLocal），避免策略一帶來的並發度限制。

三、 解決執行順序問題：synchronized 與鎖優化

使用 synchronized(this) 將關鍵業務代碼包裹為臨界區，強制串行化執行。但需注意兩大原則：

1. 縮小鎖粒度：僅同步必要代碼，避免將 I/O、Sleep、長耗時計算納入同步塊。
2. 防止死鎖：固定鎖獲取順序，避免嵌套鎖。

// 反例：Sleep 在同步塊內，嚴重降低吞吐量
synchronized(list) {
    for(...) list.add(...);
    Thread.sleep(500); // 錯誤！
}

// 正例：僅同步核心操作
synchronized(list) {
    for(...) list.add(...);
}
Thread.sleep(500); // 移至同步塊外

四、 手寫線程池：從 Socket 命令到線程生命週期管控

模擬網絡通訊場景，構建可啟動、休眠、喚醒、停止的線程池。核心組件：

• MyThread：擁有狀態機（Initial/Running/Sleeping/Stopped），run() 中通過 wait()/notify() 實現休眠喚醒。
• MyThreadManager：統一管理線程陣列，提供 Start/Stop/Sleep/Wakeup 任務分發，內部使用 synchronized(thread) 保護狀態變更。
• MyThreadPool (Server端)：ServerSocket 接受連接，每連接啟動一線程解析命令（Count/Status/StartAll/StopAll/SleepAll/WakeupAll），調用 Manager 執行。

此實踐深度揭示了線程池的本質：線程複用 + 狀態機 + 命令模式 + 同步協作。

五、 JUC 併發包核心組件全景應用

1. 線程池三巨頭

2. 線程返回值處理：Callable + Future / CompletionService

• Callable<T>：有返回值的任務單元
• Future<T>：異步結果持有者，get() 阻塞獲取
• ExecutorCompletionService：批量提交任務，take() 按完成順序獲取結果，極大簡化「多任務聚合」邏輯

3. 生產者-消費者模式：BlockingQueue

LinkedBlockingQueue 內置鎖與條件變量，put() 滿阻塞，take() 空阻塞，天然實現線程安全的緩衝區協作，無需手寫 wait/notify。

4. 信號量 Semaphore：資源訪問許可證

構造時指定許可證數（如 2），acquire() 獲取，release() 釋放。實現「同時僅 N 線程訪問資源」的流控效果，適用於資源池、限流器。

5. 線程協作屏障：CyclicBarrier vs CountDownLatch

CyclicBarrier 還支持可選的 barrierAction（屏障打開時執行的回調），適合分階段聚合計算。

六、 總結與最佳實踐

1. 優先使用無共享設計（局部變量、ThreadLocal），從根源消除同步需求。
2. 必須同步時：優先用 JUC 高級組件（Lock、BlockingQueue、Semaphore、CompletableFuture），降低 synchronized 直接使用頻率。
3. 線程池必須顯式配置：拒絕 Executors 默認工廠，自定義核心數、隊列類型、拒絕策略、線程命名、異常處理。
4. 協作選型：階段同步用 CyclicBarrier，一次性等待用 CountDownLatch，資源許可用 Semaphore，數據流轉用 BlockingQueue。