題幹與適用場景
團隊升級到 Java 25，想用緊湊物件標頭降低大量小物件的堆積使用量。請說明它改變了什麼、為何不是預設開啟，以及你會如何驗證收益與相容性。
JEP 519 把 Java 24 的實驗性緊湊物件標頭提升為 Java 25 的產品特性。64 位元架構上的物件標頭可壓縮到 64 位元，但仍需明確啟用；面試重點是理解 HotSpot 佈局、執行時選項與實測邊界。
面試官考察點
重點包括：物件標頭承載的資訊、壓縮類別指標與佈局限制、鎖與身分雜湊碼如何共存、啟用開關及預設值、堆積與 GC 指標的因果關係，以及如何設計回復與版本相容驗證。
30 秒回答框架
「我會把緊湊物件標頭視為 HotSpot 的可選記憶體佈局。JEP 519 將物件標頭從常見的 96 或 128 位元壓到 64 位元，減少每個物件的固定成本，可能改善堆積密度與資料區域性，但 Java 25 仍預設關閉。上線前我會固定 JDK、確認壓縮類別指標條件，用接近生產的物件配置基準同時比較 RSS、live set、GC 與吞吐，並保留 -XX:-UseCompactObjectHeaders 的回復路徑。」
分步驟深入解答
第一步：說明物件標頭保存什麼
HotSpot 物件標頭需要編碼類別身分、物件標記、鎖狀態、身分雜湊碼與 GC 相關資訊。緊湊佈局把這些資訊重新編碼到 64 位元字中；它改變的是 VM 記憶體表示，不會改變 Java 物件欄位或語言語意。
第二步：解釋大小收益
傳統 64 位元設定下，物件標頭通常為 96 位元，關閉壓縮類別指標時可為 128 位元。緊湊物件標頭目標是 64 位元，因此每個物件最多節省 4 或 8 位元組；收益取決於物件數量與物件本身大小，不能直接把節省比例套到整個堆積。
第三步：說明啟用條件與開關
Java 25 將開關升級為產品選項，可用以下 JVM 參數明確啟用：
java -XX:+UseCompactObjectHeaders -jar service.jar這項特性仍非預設佈局。啟動腳本、容器映像與診斷採集必須記錄完整 JVM 參數，避免不同節點使用不同物件標頭格式。
第四步：處理類別指標與類別數量邊界
緊湊佈局依賴壓縮類別指標的編碼空間。類別載入規模、動態代理與模組數量會影響是否適合啟用；不能只在本地小程式上驗證。應在接近生產的類別路徑、代理產生與啟動參數下確認 VM 能正常啟動。
第五步：分析鎖與身分雜湊碼
物件標頭中的位元同時參與鎖狀態與身分雜湊碼管理。synchronized、wait/notify、System.identityHashCode 等路徑必須納入回歸；應用程式不需改動，但 VM 可能在競爭或雜湊碼出現後使用額外的監視器結構。
第六步：設計有因果的基準
建立與生產相同生命週期的物件圖，分別執行關閉與開啟兩組，預熱後重複多輪。記錄堆積峰值、live set、配置速率、GC 暫停、吞吐、啟動時間與容器 RSS，並報告信賴區間；只看一次 -Xmx 或單一延遲百分位不足以證明收益。
第七步：驗證工具與相容性
使用目標 JDK 的 GC 日誌、JFR 與 jcmd VM.flags 確認實際開關，檢查診斷工具、JVMTI agent、崩潰傾印與監控解析器。跨 JDK 小版本升級前重新跑啟動、鎖競爭、序列化與堆積傾印檢查。
第八步：制定灰度與回復
先在相同硬體與相同負載下灰度一小部分執行個體，以堆積密度與暫停時間為門檻。若啟動失敗、RSS 未下降或鎖競爭回歸，立即切換 -XX:-UseCompactObjectHeaders；保留兩套啟動參數與可比的基準資料，避免把佈局變化與其他 JDK 升級混在一次發布中。
設計取捨與邊界
記憶體密度還是診斷複雜度
小物件密集型服務可能獲得更高堆積密度，但物件標頭編碼與工具支援更複雜。若服務物件少而大，收益可能低於升級風險，應先用配置剖析確認物件標頭占比。
吞吐還是暫停時間
更小的物件不等於所有 GC 指標都改善。減少堆積占用可能降低掃描量，也可能因新的鎖或雜湊路徑改變尾延遲；決策應同時看吞吐、暫停與錯誤預算。
產品開關還是預設策略
JDK 25 的產品選項不代表預設開啟。團隊應把開關寫入執行時基線，並在映像、啟動器與故障排查手冊中明確目前值。
失敗演練與演進計畫
動態代理導致啟動失敗
在啟用選項的完整服務中產生代理類別並啟動，記錄 VM 錯誤；若類別指標編碼空間不足，回復開關並減少一次發布中的其他變數。
身分雜湊碼路徑回歸
對大量物件呼叫 System.identityHashCode，同時執行鎖競爭與 wait/notify，比較暫停、吞吐與監視器數量。
觀測資料無法對齊
若 JFR、GC 日誌與容器指標的時間窗不同，先統一取樣窗口與預熱階段，再重新比較；不能用不同負載下的最大值下結論。
常見誤區與追問
誤區一：認為每個物件都會固定節省八位元組
追問：為什麼不能直接按物件數乘八？物件標頭大小取決於原佈局與壓縮類別指標，且物件對齊、陣列佈局、TLAB 碎片與其他堆積結構都會影響總量。
誤區二：認為產品選項就是預設設定
追問：Java 25 是否預設開啟？沒有，必須明確使用 UseCompactObjectHeaders，啟動參數應納入設定基線。
誤區三：只用吞吐基準證明成功
追問：還要看什麼？至少要看 live set、RSS、GC 暫停、鎖競爭、身分雜湊碼路徑與診斷工具相容性。
延伸追問與參考答案
哪類服務最值得優先驗證？
物件數量巨大、物件平均很小且堆積受限的服務最可能受益，例如高併發快取、事件解析與短生命週期請求物件；物件少而大時優先級較低。
為什麼不能把 Java 24 實驗結果直接用於 Java 25？
Java 25 將特性從實驗狀態變為產品選項，VM、啟動參數與工具鏈可能變化；應在目標 JDK 上重新建立基準和回復流程。
如何證明收益來自緊湊物件標頭？
固定硬體、JDK 建置、GC、堆積參數、資料集與預熱，只切換 UseCompactObjectHeaders，並重複執行後比較同一組指標。