破除 Java 迷思：線程喚醒順序與優先級無關

多線程等待/通知機制中，notify() 喚醒單一線程，notifyAll() 喚醒所有等待線程。許多開發者錯誤假設喚醒順序遵循優先級或等待時長，實則 JVM 規範不保證任何喚醒順序，完全依賴實現。

核心誤區

• 迷思 1：高優先級線程優先被喚醒
• 迷思 2：等待最久的線程優先被喚醒
• 事實：喚醒順序不確定，可能是最高優先級，可能是等待最久，也可能是任意線程

為何不可依賴優先級調度

• 線程調度為 Implementation-dependent（實現相關）
• 不同平台（Windows/Linux/Solaris）調度策略差異巨大
• Java 僅定義 1-10 優先級，底層 OS 可能支援較少層級，映射不一致
• 可移植程式碼不應對調度順序做任何假設

兩種控制喚醒順序的方案

1. 精確通知模式

Tom Cargill 提出，為每組需協同喚醒的線程分配獨立鎖物件，透過釋放特定鎖實現可控通知順序。實現成本低，但增加編碼複雜度。

2. 實時規範 JVM (RTSJ)

javax.realtime 保證等待隊列按優先級排序，notify/notifyAll 喚醒最高優先級線程。代價：鎖定特定 JVM，犧牲可移植性。原則：及時性優於執行速度，僅適用硬實時系統。

最佳實踐建議

1. 永不假設喚醒順序，設計演算法時視為非確定性
2. 優先使用 notifyAll() 而非 notify()，避免信號遺失導致線程永久飢餓
3. 若需有序喚醒，採用精確通知模式或顯式同步協協調（如 CountDownLatch、CyclicBarrier）
4. 避免依賴 Thread.setPriority() 控制業務邏輯順序

結論

Java 線程喚醒機制刻意不指定順序，賦予 JVM 實現最大優化彈性。開發者應接受非確定性，使用標準併發工具類（JDK 1.5+ java.util.concurrent）構建可靠的同步協議，而非依賴不可移植的調度行為。