Java 線程調度深度解析：搶佔式、時間片、優先級與跨平台行為差異

Java 線程調度行為由 JVM 實現決定，規範不強制要求搶佔式或時間片輪轉。本文基於《Java 線程調度》原著核心內容，深度剖析搶佔與時間片的區別、Solaris/Windows 平台差異、優先級語義的不可靠性、可運行池模型，以及開發者唯一可依賴的控制手段——wait() 與 sleep()。

一、核心概念辨析：搶佔 ≠ 時間片

• 搶佔式調度：高優先級線程可打斷低優先級線程搶佔 CPU；同優先級線程不一定會時間片輪轉。
• 時間片輪轉：每個線程分配固定時間片，時間片耗盡強制讓出 CPU，實現同優先級公平輪轉。
• 常見誤區：將「搶佔」等同於「時間片」。實際上：搶佔基於優先級，時間片基於公平性，兩者正交。

二、平台相關的調度行為差異

規範承諾：跨 JVM 實現無絕對搶佔或時間片保證。唯一可移植的線程控制手段是 wait()、sleep()、join()、LockSupport.park() 等顯式同步/阻塞 API。

三、搶佔式調度器模型

• 可運行線程按優先級分組放入可運行池（實現常用隊列）。
• 最高優先級非空池中的線程獲得 CPU 執行權。
• 運行線程持續執行直到：
  1. 主動放棄（sleep()、yield()、wait()、IO 阻塞）。
  2. 更高優先級線程變為可運行（搶佔）。
  3. 時間片耗盡（若實現時間片）。

四、優先級的不可靠性

1. 大多數 JVM 表現為搶佔式優先級，但規範不保證優先級有任何語義。
2. Windows 平台干擾：OS 線程優先級映射可能導致 Java 優先級 4 線程運行而優先級 5 線程等待。
3. 結論：不可依賴優先級實現業務正確性（如互斥、協作邏輯），僅可作為性能調優提示。

五、線程阻塞與狀態轉換

線程從可運行變為阻塞的典型原因：

• Thread.sleep(ms)：主動暫停指定時間，不釋放鎖。
• Object.wait()：等待通知，**放鎖**進入等待集。
• 同步鎖競爭：synchronized、Lock.lock() 獲取不到鎖進入阻塞隊列。
• IO 操作：InputStream.read()、Socket.accept() 等原生阻塞調用。

阻塞線程條件滿足（超時、被通知、鎖釋放、IO 就緒）後，重新進入可運行池等待調度。

六、開發者可依賴的控制手段

既然調度器行為不可移植，正確的多線程程序必須基於顯式同步構建：

1. 互斥：synchronized / ReentrantLock 保護共享數據。
2. 協作：Object.wait/notify / Condition.await/signal / CountDownLatch / Semaphore 實現線程間條件等待。
3. 可見性：volatile / final / 鎖 保證內存可見性。
4. 有序性：volatile / 鎖 禁止指令重排。

絕不使用 Thread.yield()、Thread.setPriority()、忙等待循環作為同步手段。

七、實戰啟示

• 測試併發代碼時，**在多平台（Linux/Windows/macOS）、多 JVM 版本、多核/單核環境**下運行，暴露調度敏感 Bug。
• 使用 jstack、Java Mission Control、async-profiler 分析線程狀態、鎖競爭、CPU 熱點。
• 採用 java.util.concurrent 高級組件，將調度細節委託給經過驗證的框架實現。

理解調度器的不確定性，才能編寫出真正健壯、可移植的 Java 併發程序。