前言：JVM 調優的系統性思維
JVM 調優非單一參數調整，而是業務場景 → 壓測基線 → 瓶頸定位 → 參數調優 → 驗證回歸的工程化過程。本文系統梳理堆內存劃分、GC 算法選型、關鍵參數配置、日志分析、實戰調優策略，構建完整知識體系。
一、堆內存結構與核心參數
內存區域劃分 (JDK 8 為例)
JVM 進程內存
├── 堆
│ ├── 年輕代
│ │ ├── Eden
│ │ ├── Survivor 0 (S0)
│ │ └── Survivor 1 (S1)
│ └── 年老代
├── 元空間 (Metaspace, 替代永久代)
├── 代碼緩存
├── 線程棧 (-Xss)
├── 直接內存 (-XX:MaxDirectMemorySize)
└── 操作系統保留
核心堆參數速查表
| 參數 | 含義 | 典型建議 |
|---|
-Xms | 初始堆大小 | 設為 -Xmx 同值，避免震蕩 |
-Xmx | 最大堆大小 | 物理內存 60%-80%，留給元空間、線程棧、OS |
-Xmn | 年輕代大小 | 堆的 1/3 ~ 3/8，Sun 建議 3/8 |
-XX:NewRatio | 年老代/年輕代比值 | 4 表示 1:4 (年輕代佔 1/5) |
-XX:SurvivorRatio | Eden/Survivor 比值 | 8 表示 8:1:1 (單 Survivor 佔年輕代 1/10) |
-Xss | 線程棧大小 | 256k-1M，根據線程數與棧深度調整 |
-XX:MetaspaceSize | 元空間初始大小 | 128M-256M，避免頻繁擴容觸發 Full GC |
-XX:MaxMetaspaceSize | 元空間最大值 | 限制防止 OOM，256M-512M |
-XX:MaxTenuringThreshold | 對象晉升年老代年齡閾值 | 0 直接進老年代 (適合老年代多)；15 預設 (適合年輕代回收率高) |
典型配置模板 (8G 內存服務器，JDK 8)
-Xms4g -Xmx4g -Xmn1536m
-XX:MetaspaceSize=256m -XX:MaxMetaspaceSize=512m
-Xss512k
-XX:SurvivorRatio=8
-XX:MaxTenuringThreshold=15
-XX:+UseParNewGC -XX:+UseConcMarkSweepGC
-XX:CMSInitiatingOccupancyFraction=75
-XX:+UseCMSInitiatingOccupancyOnly
-XX:+PrintGCDetails -XX:+PrintGCDateStamps -Xloggc:/logs/gc.log
二、垃圾收集器選型決策樹
三大收集器對比 (JDK 8)
| 收集器 | 線程模式 | 算法 | 目標 | 適用場景 |
|---|
| Parallel Scavenge + Parallel Old | 多線程並行 | 標記-複製/整理 | 吞吐量優先 | 科學計算、批處理、後台任務、無響應時間要求 |
| ParNew + CMS | 多線程並行 + 並發 | 標記-複製 + 標記-清除 | 響應時間優先 | Web 應用、API 服務、低延遲要求系統 |
| G1 (JDK 9+ 默認) | 多線程並行 + 並發 | 標記-整理 (區域化) | 可控停頓、大堆 | 6G+ 堆、混合負載、需可預測停頓 |
並行收集器 (吞吐量優先) 關鍵參數
-XX:+UseParallelGC # 年輕代並行
-XX:+UseParallelOldGC # 年老代並行 (JDK 6+)
-XX:ParallelGCThreads=20 # GC 線程數，建議 = CPU 核心數
-XX:MaxGCPauseMillis=100 # 目標最大停頓 (年輕代)，JVM 自動調整年輕代大小
-XX:GCTimeRatio=19 # GC 時間佔比 1/(1+19)=5%，JVM 自動調整堆大小
-XX:+UseAdaptiveSizePolicy # 自適應調整 (默認開啟)，配合上述目標動態調優
CMS 收集器 (響應時間優先) 關鍵參數
-XX:+UseConcMarkSweepGC # 啟用 CMS (年老代)
-XX:+UseParNewGC # 年輕代並行 (CMS 推薦搭配)
-XX:CMSInitiatingOccupancyFraction=75 # 老年代佔用 75% 觸發 CMS
-XX:+UseCMSInitiatingOccupancyOnly # 僅使用佔用比例觸發，不自適應
-XX:+UseCMSCompactAtFullCollection # Full GC 時壓縮整理 (消除碎片)
-XX:CMSFullGCsBeforeCompaction=5 # 每 5 次 Full GC 壓縮一次
-XX:ParallelCMSThreads=4 # CMS 並發線程數
-XX:ConcGCThreads=4 # 並發標記線程數
CMS 痛點：浮動垃圾、內存碎片、CPU 敏感、無法處理「晋升失敗」。JDK 9 標記棄用，JDK 14 移除。新項目首選 G1/ZGC。
三、GC 日志分析與可視化工具
核心日志參數
| 參數 | 輸出示例 | 用途 |
|---|
-XX:+PrintGC | [GC 118250K->113543K(130112K), 0.0094 secs] | 基礎 GC 信息 |
-XX:+PrintGCDetails | [GC [DefNew: 8614K->781K(9088K), 0.0123 secs] 118250K->113543K(130112K), 0.0125 secs] | 詳細分代信息 |
-XX:+PrintGCTimeStamps | 11.851: [GC ...] | 相對時間戳 |
-XX:+PrintGCDateStamps | 2023-01-01T10:00:00.123: [GC ...] | 絕對時間戳 (推薦) |
-Xloggc:/path/gc.log | 文件輸出 | 持久化分析 |
-XX:+PrintHeapAtGC | GC 前後完整堆快照 | 深度分析 |
推薦分析工具
- GCeasy (在線、免費、圖表豐富)
- GCEasy.io / GCViewer (桌面版)
- Arthas / jstat / jmap / jhat (線上診斷)
- Prometheus + Grafana + jmx_exporter (生產監控體系)
四、實戰調優策略
1. 年輕代大小選擇
| 應用類型 | 策略 | 理由 |
|---|
| 響應時間敏感 (Web/API) | 盡可能大，接近系統最低響應時間限制 | Minor GC 頻率最低、減少對象晉升老年代、停頓時間可控 |
| 吞吐量敏感 (批處理/計算) | 極大 (甚至 GB 級)，配合 8+ CPU | 批量回收短命對象、並行 GC 效率高、無響應時間壓力 |
2. 年老代大小選擇
- CMS：需精細測試。考慮並發會話率、會話持續時間、對象晉升速率。過小 → 碎片/頻繁 Full GC/退化 Serial Old；過大 → Full GC 停頓長
- Parallel Old：通常較小即可，因年輕代大多數短命對象已回收，老年代存長期對象
3. 碎片問題應對 (CMS/Parallel Old)
-XX:+UseCMSCompactAtFullCollection # Full GC 時壓縮
-XX:CMSFullGCsBeforeCompaction=0 # 每次 Full GC 都壓縮 (CMS)
# Parallel Old 自動壓縮 (標記-整理算法)
4. 典型故障現象與應對
| 現象 | 可能原因 | 排查方向 |
|---|
| 頻繁 Minor GC | 年輕代過小 / 分配速率極高 | 增大 -Xmn、檢查大對象直接進老年代 (-XX:PretenureSizeThreshold) |
| 頻繁 Full GC | 老年代不足 / 內存洩漏 / 顯式 System.gc() / CMS 晋升失敗 | jmap -histo:live 找大對象、MAT 分析洩漏、禁用 System.gc() (-XX:+DisableExplicitGC) |
| GC 停頓過長 | 堆過大 / 老年代碎片 / CMS 並發失敗退化 | 縮小堆/分拆服務、啟用壓縮、遷移 G1/ZGC |
| 元空間 OOM | 類加載過多 / 動態代理 / 類加載器洩漏 | 增大 Metaspace、檢查動態生成類 (CGLIB、JSP、Groovy) |
| 直接內存 OOM | NIO ByteBuffer / Netty / 堆外緩存未釋放 | -XX:MaxDirectMemorySize 限制、Reflection 清理 DirectBuffer、升級 Netty |
五、新世代 GC (JDK 11+) 選型建議
| 收集器 | 特點 | 適用場景 | 關鍵參數 |
|---|
| G1 | 區域化、可預測停頓、混合 GC、大堆友好 | 6G+ 堆、綜合業務、JDK 9+ 默認 | -XX:MaxGCPauseMillis=200 -XX:InitiatingHeapOccupancyPercent=45 |
| ZGC | 亞毫秒停頓、多映射內存、可擴展至 TB 級 | 超大堆 (100G+)、極低延遲要求、JDK 11+ | -XX:+UseZGC -Xmx100g |
| Shenandoah | 並發整理、低停頓、Red Hat 主導 | 大堆、低延遲、OpenJDK 派系 | -XX:+UseShenandoahGC |
六、調優避坑指南
- 不盲目複製參數：每個應用內存佔用模式不同，必須基於壓測數據調優
- 單變量原則：每次調整一個參數，觀察 GC 日志與業務指標 (QPS、RT、錯誤率)
- 關注業務指標而非 GC 指標：GC 頻率低但 RT 高 = 沒意義；目標是業務 SLA 達標
- 預留內存紅線：堆 + 元空間 + 直接內存 + 線程棧 + CodeCache < 物理內存 80%
- 建立基線：新版本上線前必跑全鏈路壓測，對比 GC 日志與業務指標
總結
JVM 調優是內存模型理解、GC 算法原理、參數工程實踐、觀測體系建設的綜合考驗。從「背參數」進化到「懂原理、會分析、能決策」，核心在於：
- 建立 業務負載 → 內存分配模式 → GC 行為 → 參數調整 的因果鏈路思維
- 掌握
jstat/jmap/GC 日志/Arthas 等觀測工具鏈
- 擁抱新版本：JDK 11+ 遷移 G1/ZGC，享受亞毫秒停頓與自適應優化紅利
最好的調優是架構層面解決問題：拆分服務、引入緩存、異步化、流控降級。參數調優是戰術，架構優化是戰略。
