Eclipse Debug 模式下為何不會發生指令重排序？

Java 編譯器與 JIT 編譯器為了效能會對指令進行重排序，但在 Eclipse（或 IntelliJ IDEA、VS Code 等）的 Debug 模式下，程式碼卻嚴格按源碼順序逐行執行。這背後的機制其實很簡單：

核心原因：Debug 編譯關閉優化

• 編譯參數：Eclipse 啟動 Debug 時，自動為專案加上 -g 參數（生成行號、局部變數表等除錯資訊），且不啟用 -O 優化選項。
• JIT 行為：JVM 偵測到方法帶有 LineNumberTable、LocalVariableTable 等除錯屬性，且方法未被標記為 Compiled（或被標記為 !Optimized），解譯器/客戶端編譯器會跳過指令重排序、內聯、逃逸分析等激進優化。
• 斷點映射：為了讓斷點精準對應源碼行，JVM 必須保證字節碼執行順序與源碼順序一致，任何重排序都會導致斷點位置錯亂、變數值不可預期。

其他 IDE 同理

IntelliJ IDEA、NetBeans、VS Code (Java Extension) 等皆採用相同策略：Debug 模式 = 無優化編譯 + 完整除錯資訊。這不是 Eclipse 獨有，而是 JVM 除錯架構（JDWP/JDI）的標準需求。

副作用與注意點

• 效能極低：關閉優化後執行速度可能較 Release 模式慢 10~100 倍，不適合效能測試。
• assert 生效：Debug 模式預設啟用斷言（-ea），Release 通常關閉，導致行為差異。
• 最終驗證仍需 Release Build：多執行緒、volatile、final 語義在優化後才會展現真實行為，發布前務必用 javac -O / maven profile=release 完整建置並測試。

進階：如何在 Debug 時觀察真實重排序？

1. 在 launch configuration → Arguments → VM arguments 加入 -XX:+UnlockDiagnosticVMOptions -XX:+LogCompilation -XX:LogFile=jit.log。
2. 使用 JITWatch 分析編譯後的組合語言，查看指令排程。
3. 或編寫 jcstress 並發測試，在 Release 模式下驗證記憶體可見性問題。

總結：Debug 模式為了「可除錯」犧牲了「優化」，這是所有主流 Java IDE 的共同設計決策。理解這一點，能避免在除錯時對執行順序產生錯誤預期。