JVM 实战调优
调优不是盲目堆参数，而是"观察现状 → 形成假设 → 小步验证"的循环。本文围绕 GC 日志分析、参数优化思路、案例复盘与容器适配四个方向展开。
GC 日志开启与解读
日志参数
JDK 8 与 JDK 9+ 的日志参数不同：
bash
# JDK 8
-XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:+PrintGCDateStamps
-Xloggc:/opt/logs/gc.log
# JDK 9+（统一日志）
-Xlog:gc*:file=/opt/logs/gc.log:time,uptime,level,tags推荐格式（JDK 9+）：
bash
-Xlog:gc*=info,gc+ref*=debug,gc+ergo*=trace:file=/opt/logs/gc.log:time,level,tags一条 Minor GC 日志解读
[GC (Allocation Failure) [PSYoungGen: 102400K->10240K(307200K)] 102400K->7680K(983040K), 0.025s]| 片段 | 含义 |
|---|---|
| Allocation Failure | 新生代分配失败触发 GC |
| 102400K->10240K(307200K) | 新生代回收前→回收后（新生代总容量） |
| 102400K->7680K(983040K) | 堆回收前→回收后（堆总容量） |
| 0.025s | GC 耗时 |
关注的核心指标
- GC 频率：Minor GC 间隔是否过短（<1s 需警惕）
- Full GC 次数：高频 Full GC 是调优的第一信号
- 晋升速率：每秒晋升老年代的量，决定老年代何时被打满
- 停顿时长：单次停顿是否超过服务容忍阈值
参数优化思路
先判断调优方向
| 症状 | 方向 |
|---|---|
| 响应慢、停顿长 | 缩短 GC 停顿（G1/ZGC、调小 MaxGCPauseMillis） |
| 吞吐低、批处理慢 | 提升吞吐（Parallel、避免频繁 GC） |
| 高频 Full GC | 老年代压力大，调大堆或减少晋升 |
| OOM | 先定位泄漏，再谈参数 |
堆大小原则
1. -Xms 与 -Xmx 设为一致（避免运行期扩容抖动）
2. 堆大小不超过物理内存的 70%-80%，留出元空间/线程栈/直接内存
3. 新生代一般占堆 1/3 ~ 1/2，看对象存活率调整
4. 大对象多的应用，适当调大老年代或 Region常见参数组合示例
bash
# 低延迟场景（G1）
java -Xms4g -Xmx4g -XX:+UseG1GC \
-XX:MaxGCPauseMillis=100 \
-XX:+HeapDumpOnOutOfMemoryError \
-XX:HeapDumpPath=/opt/logs \
-Xlog:gc*=info:file=/opt/logs/gc.log:time
# 高吞吐场景（Parallel）
java -Xms4g -Xmx4g -XX:+UseParallelGC \
-XX:GCTimeRatio=19 \
-Xlog:gc*=info:file=/opt/logs/gc.log:time全链路调优案例复盘
案例一：接口响应偶发超时
现象：GC 停顿偶尔超过 500ms，接口超时
jstat -gcutil：Full GC 约每 2 分钟一次，FGCT 累增
原因：老年代频繁被打满，触发 Full GC（Parallel Old STW 全停）
分析：
1. 堆 2g 偏小，峰值流量下老年代不足
2. 缓存对象无过期，长期驻留老年代
调整：
1. -Xmx 2g → 4g，-Xms 同步
2. 缓存改用 Caffeine 带过期策略
结果：Full GC 频率从每 2 分钟降到几乎消失案例二：大对象引发频繁 Mixed GC
现象：G1 下 FGC 明显，日志出现 humongous allocation 失败
jcmd GC.heap_info：多个 humongous region 占用
原因：业务一次性创建超大数组/List，直接分配多个连续 Region
调整：
1. -XX:G1HeapRegionSize 从默认 1MB 调大到 16MB，容纳大对象
2. 代码侧拆分大对象，避免单次分配超大空间
结果：Full GC 消除，停顿恢复稳定案例三：容器内存 OOM 被 kill
现象：容器反复 OOMKilled，JVM 日志无 OOM
原因：JVM 默认按物理机内存计算堆大小，容器限 1g 而 JVM 认为有 32g
调整：加 -XX:MaxRAMPercentage=75（按容器配额计算）
结果：JVM 堆按容器配额自适应，不再被 kill容器环境 JVM 适配
容器场景与物理机最大的差异：JVM 需要感知容器配额。
关键问题
- JVM 默认按宿主机物理内存计算默认堆（-Xmx 未显式设置时）
- 容器限内存 1g，JVM 可能按宿主机 32g 计算，直接 OOMKilled
适配参数
bash
-XX:+UseContainerSupport # JDK 10+ 默认开启容器感知
-XX:MaxRAMPercentage=75 # 堆上限 = 容器可用内存 75%
-XX:InitialRAMPercentage=50
-XX:MinRAMPercentage=50| 参数 | 说明 |
|---|---|
| MaxRAMPercentage | 最大堆占容器内存百分比（推荐 75% 左右） |
| InitialRAMPercentage | 初始堆百分比 |
| MinRAMPercentage | 最小堆百分比（小内存容器时） |
容器适配检查清单
- 确认 JDK 版本支持容器感知（10+ 默认支持）
- 显式设置
MaxRAMPercentage，避免隐式默认值 - 预留非堆内存：元空间、线程栈、直接内存通常占 20%-30%
- CPU 限制场景：
-XX:ActiveProcessorCount告知 JVM 可用 CPU 数，避免 GC 线程数误判
调优总原则
- 先正确，再调优：功能正确、无泄漏是前提，参数是最后的手段
- 数据驱动：一切调整以 GC 日志、监控指标为依据，禁止拍脑袋堆参数
- 单变量验证：一次只改一个参数，观察效果再动下一个
- 留有余量：堆、直接内存、线程数都留缓冲，避免边缘状态崩溃
- 自动化观测：接入监控（Prometheus/Grafana）与告警，让调优持续化而非一次性