題幹與適用情境
你負責一個頻繁啟動、尖峰流量變化明顯的 Java 服務。面試官要求你評估 JDK 25 的 AOT 方法剖析：訓練執行收集方法執行 profile，生產啟動時把 profile 放入 AOT cache，讓 JIT 更早編譯熱點方法。請說明基線、訓練流量、快取發布與回滾方案。
題目考察 JVM 效能診斷與發布工程，不要求背誦某個啟動參數。假設服務仍會在生產中繼續線上剖析，且訓練輸入可能與生產輸入不完全相同。
面試官考察點
- 能否區分 AOT cache、AOT profile 與把 Java 方法直接編譯成固定機器碼。
- 能否解釋訓練資料為何可能失真，以及如何用生產形狀的流量降低失真。
- 能否用可重複的指標證明預熱改善，而不是把一次冷啟動偶然變快當成結論。
- 能否設計快取版本、硬體、JDK 更新與回滾邊界。
普通回答只會說「預熱更快」。強回答會說明 profile 如何影響 JIT、生產仍會重新取樣、快取怎樣驗證，以及何時放棄 AOT。
回答前需要釐清的問題
- 服務是短命函式、滾動發布中的新實例，還是長時間執行的單體？實例壽命決定預熱成本是否值得。
- 生產請求是否有穩定的熱點路徑？若請求類型高度隨機，單一訓練 profile 的收益可能很小。
- 訓練與生產的 JDK、CPU 架構、啟動參數、類別路徑是否完全一致？不一致時快取必須隔離或重建。
- 需要優化的是第一個請求延遲、達到穩定吞吐的時間，還是總 CPU 成本？不同目標會改變停止規則。
30 秒回答框架
「我先保留不帶 AOT profile 的冷啟動與穩態基線，再用生產形狀的代表流量做訓練並產生快取。灰度時同時記錄第一個請求、達到穩態吞吐的時間、p95/p99、CPU、RSS、錯誤率與快取建置成本。JDK 25 的 profile 只讓 JIT 更早、更準確地工作，生產仍會線上剖析，因此我會按 JDK、映像檔、硬體與類別路徑綁定快取。若收益在信賴區間內不穩定，或出現反最佳化與記憶體回歸，就關閉快取並回到無快取映像檔。」
分步驟深入解答
1. 先建立可比較的基線
固定 JDK 25 的修補版本、容器映像檔、CPU 配額、堆積參數與類別路徑。至少跑三組：無 AOT cache、只有類別載入與連結快取、包含方法 profile 的快取。每組都重複冷啟動與穩態實驗，記錄啟動到 ready、第一個請求、達到目標吞吐的時間、p50/p95/p99、CPU 時間、RSS、JIT 編譯量與錯誤率。
JEP 515 的核心變化是把訓練執行中的方法執行 profile 放進 AOT cache；它不會阻止生產繼續剖析。因此「快取後所有請求都固定走訓練路徑」是錯誤模型。
2. 設計訓練執行
訓練資料應涵蓋真實路由、租戶規模、序列化格式、快取命中與未命中、例外路徑與常見設定。只壓測健康路徑會讓 profile 偏向錯誤熱點。訓練完成後，檢查請求分布與最近生產視窗的差異，並把訓練輸入版本寫入快取清單。
若服務有明顯季節性，至少為不同流量形狀產生不同快取；不要把低峰 profile 強行用於高峰版本。
3. 選擇一鍵或兩步產生流程
JDK 25 的 -XX:AOTCacheOutput=app.aot 可把常見訓練與快取建立合併到一次啟動。資源受限時使用明確兩步流程更安全：訓練階段記錄設定，另一個資源更充足的環境建立快取。JEP 514 特別提醒，一鍵流程的快取建立子程序會使用與訓練相同大小的 Java heap；例如兩階段都設定 4 GB 堆積，峰值記憶體可能接近 8 GB。
java -XX:AOTCacheOutput=app.aot -cp app.jar com.example.App
java -XX:AOTCache=app.aot -cp app.jar com.example.App4. 把快取當作有邊界的建置產物
快取鍵至少包含 JDK 精確版本、作業系統、CPU 架構、類別路徑或映像檔 digest、啟動參數與訓練資料版本。發布系統在啟動前校驗這些欄位；任何不匹配都回退到無快取啟動。快取不應跨不同 CPU 指令集或不同位元組碼版本重用。
5. 用灰度驗證收益與失效
先讓少量實例使用 profile cache，並與同批無快取實例在相同時間窗做對照。關注達到穩態吞吐所需的時間，而不是只看程序 ready。若第一個請求變快但 p99、CPU 或 RSS 變差，代表最佳化目標選錯。生產繼續線上剖析時，要觀察是否頻繁反最佳化；反最佳化代表訓練行為與生產行為不一致。
6. 設定回滾與更新規則
快取應可獨立撤回。映像檔保留無快取啟動路徑，發布控制器透過設定選擇 -XX:AOTCache；錯誤率、p99 或 RSS 超過門檻就停止灰度並移除該參數。JDK 修補版、依賴、路由或關鍵設定改變後重新訓練，不能把舊快取當作永久資產。
高品質示範回答
我會把它當成受版本約束的效能建置產物來評估。先固定 JDK 25、映像檔、CPU 與堆積參數，比較無快取、類別載入快取與帶方法 profile 的 AOT cache。訓練流量要涵蓋真實熱點與例外路徑，並記錄輸入版本。灰度階段看第一個請求、達到穩態吞吐的時間、p95/p99、CPU、RSS、反最佳化次數與錯誤率。JEP 515 的 profile 只是讓 JIT 更早取得歷史觀察，生產仍會線上剖析，所以我不會承諾固定收益。快取鍵綁定 JDK、架構、類別路徑與訓練版本；不匹配就回退。若收益只出現在冷啟動，或生產行為造成反最佳化、p99 或記憶體回歸，我會關閉快取，保留無快取映像檔並重新訓練。
常見錯誤
- 錯誤表現 → 把 AOT profile 說成完整原生編譯 → 誤解 JEP 515，快取的是方法執行 profile，JIT 仍會在生產編譯；修正方法：明確區分 profile cache、類別載入快取與未來可能的 AOT 程式碼。
- 錯誤表現 → 只用一條健康路徑訓練 → 生產的例外、租戶與長尾請求會造成行為偏移；修正方法：按流量分布涵蓋關鍵邊界並記錄訓練版本。
- 錯誤表現 → 只比較程序 ready 時間 → ready 變快不等於達到穩態吞吐更快；修正方法：同時測第一個請求、穩態延遲、CPU、RSS 與反最佳化。
- 錯誤表現 → 跨 JDK 或 CPU 重用快取 → 類別路徑、指令集與執行期假設可能不相容；修正方法：把這些欄位寫入快取清單並嚴格校驗。
追問及應對
如果訓練資料與生產流量差異很大怎麼辦？
先按路由、租戶、回應碼與序列化類型比較分布。差異超過預設門檻時停止發布該快取，補充訓練樣本或為不同流量形狀分別建立快取。生產線上剖析可以修正，但不能取代基本訓練覆蓋。
一鍵 AOT 快取建立在 CI 中 OOM，怎麼處理？
改用明確兩步流程，把訓練放在貼近生產的環境，把建立快取放到更大機器，並檢查兩個階段的 JDK、類別路徑與啟動參數。也可以降低堆積或拆分訓練，但必須重新量測 profile 覆蓋與建置時間。
灰度中 p99 變差但啟動變快，是否繼續？
停止擴大灰度。先確認 CPU、RSS、反最佳化、GC 與請求分布是否變化；若 p99 回歸無法解釋或超過業務門檻，立即回滾到無快取版本。只有找到可重現原因並用新快取修復後，才重新進行對照實驗。