Java 併發編程現狀與發展趨勢：從 synchronized 到 J.U.C 的演進之路

多核時代催生併發編程新需求

隨著多核處理器普及且成本大幅下降，併發編程已成為現代 Java 開發的核心技能。硬體並行能力的釋放，倒逼軟體架構從傳統同步機制向高性能併發框架演進。

傳統同步機制的核心痛點

1. 無法區分「共享讀」與「互斥寫」

synchronized、Object.wait()/notify() 等內置機制採用完全排他鎖：只要存在併發寫入可能，所有讀操作也被迫串行化。這與「讀多寫少」的典型業務場景嚴重不符，導致硬體新增的並行能力在普通應用中大打折扣。

2. 靈活性受限

• wait()/notify() 必須在同步塊內調用，否則拋出 IllegalMonitorStateException
• 單個對象僅能關聯一組 wait/notify 狀態，無法針對不同業務條件分別等待

J.U.C (java.util.concurrent) 的突破與代價

核心優勢

• 讀寫分離：ReentrantReadWriteLock 允許併發讀、互斥寫，充分利用多核優勢
• 多條件變量：一個 Lock 可創建多個 Condition，精準控制線程喚醒
• 硬體級原子操作：基於 sun.misc.Unsafe 直接調用 CPU 指令（CAS），從軟體鎖升級為硬體實現，性能大幅提升

不可忽視的代價

• 語法冗長：手動 lock()/unlock() 易忘釋放鎖，不如 synchronized 代碼塊優雅（編譯器自動匹配大括號）
• 單線程優化犧牲多線程：JVM 對單線程同步塊極度優化（偏向鎖、輕量級鎖），但多線程爭用時性能反而不如預期

基礎構建塊：Executor、Future、BlockingQueue

這些組件已成為構建應用服務器的標準塊，作為 JDK 標準庫提供，有利於孵化優秀框架。但主流業務開發是否應直接建立在這些底層工具之上，仍需審慎評估——上層框架（如 Spring、Netty）往往提供更高級別的抽象。

從 dl.u.c 到 j.u.c 的架構躍遷

早期 dl.u.c (Doug Lea's util.concurrent) 構建於傳統同步機制之上；而 j.u.c 直接移植到 HotSpot VM 的併發特性，通過 Unsafe 產生原子內存訪問指令，實現了從軟體實現到硬體實現的質變，性能差異顯而易見。

總結與展望

Java 併發編程正處於「傳統優雅」與「高性能靈活」的權衡期。未來隨著 Virtual Threads (Project Loom) 等新特性落地，或將在語言層面重新定義併發模型，讓開發者既享受結構化併發的簡潔，又榨乾多核硬體性能。