一次 GC 引發的 CPU 100% 故障定位實戰復盤

從「以為是計算慢」到「原來是 GC 暴走」：一場 400萬×96 循環的性能調優實戰

同事反饋一段代碼執行極慢，CPU 長期 100%。經歷「優化計算邏輯 → 引入多線程 → 仍無效」的彎路後，最終通過擴大堆內存驗證假設，定位到頻繁 Full GC 導致業務線程饑餓。本文完整復盤定位思路、根因分析與 JVM 內存參數知識，助你避開「先入為主」的調優陷阱。

故障現場還原

// 核心業務：400萬 × 96 次循環
HashMultimap map = ...;
for (int i = 0; i < 400_0000 * 96; i++) {
    Bean bean = doCompute();        // 計算耗時
    map.put(key, bean);             // 緩存結果
}

初步嘗試：優化 doCompute()、引入 ConcurrentLinkedQueue 解耦生產消費、多線程並行 → CPU 依然 100%，吞吐無提升。

關鍵轉折：-Xms20G -Xmx20G 直接跑飛

下班前靈光一試：給服務器分配 20G 堆，零修改代碼，直接跑通，CPU 正常。這一驗證瞬間推翻「計算慢」假設，鎖定內存壓力 → GC 暴走。

根因深度剖析

1. 對象產生速度極快：HashMultimap + ConcurrentLinkedQueue 每次循環新建大量 Bean、Node、Map.Entry 等短命對象
2. 堆內存漸增觸發 GC：JVM 發現 Eden 區滿 → Minor GC → 存活對象進 Survivor → 繼續滿 → 觸發 Full GC
3. Full GC 回收極少：map 持有所有結果引用，對象全是存活的，GC 掃描整個堆卻回收接近零
4. GC 佔用 100% CPU：Parallel GC 多線程並行掃描壓縮堆，業務線程幾乎無時間片
5. 不拋 OOM：堆未達 -Xmx 上限，只是在「分配 → GC → 分配 → GC」死循環中耗盡 CPU

JVM 內存擴縮容機制知識卡片

注意：free 命令顯示的可用內存 ≠ JVM 可分配內存，受 OS 頁面緩存、共享內存、碎片化影響。

調優方案對比

避坑心法總結

• 不要先入為主：看到「循環慢」先想算法優化，實則可能是 GC、鎖競爭、IO、上下文切換
• 相信 JVM 工程化水平：HotSpot 經過億級生產驗證，GC 演算法極其成熟，先懷疑業務代碼對象創建模式
• 科學驗證假設：-Xms -Xmx 設大一點跑跑看，成本最低、區分度最高
• 工具鏈必備：jstat -gcutil、jmap -histo、GC 日志 -Xlog:gc*、Arthas、JProfiler

下周計劃補上 -Xlog:gc*:file=gc.log 實測日誌驗證本文分析。記住：性能調優的本質是「找到系統真正的瓶頸在哪裡」，而不是「優化你以為的瓶頸」。