專家詳解 Java 尾遞歸優化：為什麼 JVM 不保證消除堆疊溢出？

尾遞歸轉換為迴圈能顯著提升效能並避免堆疊溢出，但 Java 語言規範不強制編譯器實現此優化。本文深入剖析靜態編譯破壞多態語義的根本矛盾，解釋 JIT 動態優化的觸發條件與不確定性，並提供實戰檢測代碼幫助開發者驗證運行環境行為。

尾遞歸優化的語義陷阱

若靜態編譯器將父類尾遞歸方法優化為迴圈，子類覆寫的守衛邏輯（如參數檢查拋異常）將被繞過，導致程式行為與語言規範定義的多態分派語義不一致。這是 Java 拒絕在語言層面承諾尾調用優化的核心原因——語義保持性優於效能優化。

JIT 編譯器的機會主義優化

HotSpot Server/Client Compiler 在運行期掌握完整類層級資訊，滿足以下條件時會將尾遞歸編譯為迴圈機器碼：

• 方法達到編譯閾值（熱點）
• 確無子類覆寫（或類層級鎖定）
• 遞歸深度可預測、無動態類載入影響

但此行為非規範保證，跨 JDK 版本、廠商、參數（如 -XX:+OptimizeTailCalls 實驗性旗標）差異極大，生產代碼不可依賴此特性。

工程決策指南

1. 默認寫迴圈：Java 慣用模式，零風險、可讀性強。
2. 受控深度遞歸可接受：樹遍歷、分治演算法，文檔標註最大深度。
3. 不可控深度必須遞歸：採用 Trampoline、顯式堆疊模擬、或切換至支援 TCO 的 JVM 語言（Scala/Kotlin 配置尾調用優化）。

理解尾遞歸優化的語義邊界與 JVM 實現現狀，能幫助開發者在表達力與穩健性間做出理性取捨，避免「寫出漂亮的遞歸，跑出醜陋的 StackOverflowError」。