企业官网建设流程全解析

30-GC 日志解读与调优实战

前面几篇分别讲了各款收集器的原理和参数，但真正的调优能力来自看懂 GC 日志 + 定位问题 + 验证效果的闭环。本篇是垃圾回收模块的收官篇，我们用真实案例串起日志格式、分析工具、调优方法，最后给出生产环境参数推荐。读完这篇，你应该能独立完成一次完整的 GC 调优。

GC 日志格式：JDK 8 vs JDK 9+

JDK 8 的传统日志

JDK 8 用-XX:+PrintGCDetails打印 GC 详情，格式是"自由文本"：

java-XX:+PrintGCDetails-XX:+PrintGCDateStamps-XX:+PrintGCTimeStamps\-Xloggc:gc.log-cpMyApp com.example.Main

输出示例：

2016-07-20T11:53:04.053+0800: 1.234: [GC (Allocation Failure) [PSYoungGen: 262144K->30720K(305664K)] 424960K->204800K(983040K), 0.0234567 secs] [Times: user=0.05 sys=0.01, real=0.02 secs] 2016-07-20T11:53:05.678+0800: 2.345: [Full GC (Ergonomics) [PSYoungGen: 30720K->0K(305664K)] [ParOldGen: 174080K->163840K(677376K)] 204800K->163840K(983040K), [Metaspace: 25600K->25600K(1073152K)], 0.2345678 secs] [Times: user=0.80 sys=0.01, real=0.23 secs]

关键字段：

• GC (Allocation Failure)：触发原因，Allocation Failure = 分配失败（Eden 满）。
• PSYoungGen：新生代名，PS 表示 Parallel Scavenge。
• 262144K->30720K(305664K)：回收前→回收后（当前总大小）。
• 424960K->204800K(983040K)：全堆 回收前→回收后（堆总大小）。
• 0.0234567 secs：本次 GC 停顿时间。
• [Times: user=0.05 sys=0.01, real=0.02 secs]：用户态、内核态、实际墙钟时间。user远大于real说明多线程并行（user = 各线程 CPU 时间之和）。

JDK 9+ 的统一日志（Xlog）

JDK 9 引入统一日志框架（JEP 158），用-Xlog:统一管理所有日志，GC 日志格式结构化、可解析：

java-Xlog:gc*=info:file=gc.log:time,uptime,level,tags\-cpMyApp com.example.Main

参数拆解：

-Xlog:<what>:<output>:<decorators>:<level> what = gc*=info（所有 GC 相关日志，info 级别） output = file=gc.log（输出到文件） decorators = time,uptime,level,tags（日志前缀格式）

输出示例：

[2026-07-17T10:00:01.234+0800][1.234s][info][gc,start ] GC(0) Pause Young (Allocation Failure) [2026-07-17T10:00:01.234+0800][1.234s][info][gc,heap ] GC(0) PSYoungGen 262144K->30720K(305664K) [2026-07-17T10:00:01.234+0800][1.234s][info][gc ] GC(0) Pause Young (Allocation Failure) 424960K->204800K(983040K) 0.0234567s [2026-07-17T10:00:01.234+0800][1.234s][info][gc,cpu ] GC(0) User=0.05s Sys=0.01s Real=0.02s

改进点：

• 结构化：每行有 tag（如[gc,heap]），便于工具解析。
• 统一格式：所有收集器用同一套日志框架，不再各写各的。
• 可过滤：-Xlog:gc*=info控制粒度，debug 级可看更多细节。

常用 Xlog 配置

# 基础（生产推荐）-Xlog:gc*=info:file=gc.log:time,uptime,level,tags# 详细（调试用）-Xlog:gc*=debug:file=gc.log:time,uptime,level,tags# 堆详情（含每次 GC 后区域占用）-Xlog:gc*=info,gc+heap=debug:file=gc.log:time,uptime,level,tags# 同时输出到控制台和文件-Xlog:gc*=info:file=gc.log:time,uptime,level,tags:gc*=info:stdout:time,level,tags

Young GC 日志解读

以 G1 的 Young GC 为例：

[1.234s][info][gc,start] GC(0) Pause Young (Normal) (G1 Evacuation Pause) [1.234s][info][gc,task] GC(0) Using 8 workers [1.234s][info][gc,heap] GC(0) Eden regions: 80->0(80) [1.234s][info][gc,heap] GC(0) Survivor regions: 0->8(8) [1.234s][info][gc,heap] GC(0) Old regions: 0->0 [1.234s][info][gc,heap] GC(0) Humongous regions: 2->2 [1.234s][info][gc] GC(0) Pause Young (Normal) 500M->200M(2048M) 5.678ms [1.234s][info][gc,cpu] GC(0) User=0.04s Sys=0.01s Real=0.005s

逐行解读：

• GC(0)：第 0 次 GC（计数从 0 开始）。
• Pause Young (Normal)：Young GC，Normal 表示常规触发（非 Mixed）。
• G1 Evacuation Pause：G1 的复制式回收。
• Using 8 workers：8 个 GC 线程。
• Eden regions: 80->0(80)：Eden 从 80 个 Region 清空到 0（共 80 个）。
• Survivor regions: 0->8(8)：Survivor 从 0 涨到 8 个。
• 500M->200M(2048M)：堆占用从 500M 降到 200M，总堆 2048M。
• 5.678ms：本次停顿。
• User=0.04s Sys=0.01s Real=0.005s：User > Real 说明多线程并行（8 线程 × 5ms ≈ 40ms user time）。

健康指标：

• 回收量：500M → 200M，回收了 300M，有效率 60%。
• 停顿：5.678ms，对 G1 来说很健康。
• 频率：看相邻两次 GC 的时间间隔，结合业务负载判断。

Full GC 日志解读

Full GC 通常是异常信号，要重点分析：

[10.234s][info][gc,start] GC(15) Pause Full (G1 Compaction Pause) [10.234s][info][gc,phases] GC(15) Phase 1: Mark live objects [10.235s][info][gc,phases] GC(15) Phase 2: Prepare compaction [10.236s][info][gc,phases] GC(15) Phase 3: Adjust pointers [10.240s][info][gc,phases] GC(15) Phase 4: Compact heap [10.241s][info][gc,heap] GC(15) Old regions: 200->50 [10.241s][info][gc] GC(15) Pause Full (G1 Compaction Pause) 1800M->600M(2048M) 6.789ms

G1 的 Full GC 分四阶段（JDK 10+ 多线程并行）：

1. Mark live objects：标记存活对象。
2. Prepare compaction：计算整理后的对象位置。
3. Adjust pointers：调整所有指向移动对象的引用。
4. Compact heap：实际搬运对象，整理碎片。

本次 Full GC：

• 触发原因：G1 Compaction Pause，通常是 Mixed GC 跟不上或碎片严重。
• 回收效果：1800M → 600M，回收 1200M（碎片整理释放）。
• 停顿：6.789ms——G1 并行 Full GC 比 CMS 的 Serial Old 快得多，但仍应避免。

触发原因分类

Allocation Failure ── 新生代分配失败（常规 Young GC） Ergonomics ── JVM 自适应决定（自适应触发） System.gc() ── 代码显式调用（应避免） G1 Compaction Pause ── G1 退化的 Full GC（调优目标） CMS Mode failure ── CMS 降级 Serial Old（JDK 8） Metadata GC Threshold── Metaspace 不足触发（类加载多）

看到System.gc()要查代码是否调用了System.gc()，或用-XX:+DisableExplicitGC禁用。

在线分析工具：GCEasy

GCEasy（gceasy.io）是最流行的在线 GC 日志分析工具。使用流程：

1. 采集日志：用-Xlog:gc*=info:file=gc.log输出到文件。
2. 上传：访问 gceasy.io，上传 gc.log。
3. 分析报告：工具返回可视化报告。

关键指标

GCEasy 报告的核心指标：

• Throughput（吞吐量）：应用运行时间占比，目标 > 95%。
• Avg GC Pause（平均停顿）：所有 GC 的平均停顿。
• Max GC Pause（最大停顿）：最差情况，关注 P99。
• Young GC / Full GC 次数：Full GC 应极少甚至为 0。
• 内存 reclaimed：每次 GC 回收的内存量。

健康判断标准

其他工具

• GCViewer：本地 Java 工具，离线分析，适合内网环境。
• JDK Mission Control（JMC）：JDK 11+ 自带，关联 GC 事件与应用行为。
• VisualVM：可视化监控，含 GC 插件。
• Prometheus + Grafana：生产监控，通过 JMX Exporter 采集 GC 指标。

调优案例

案例1：新生代太小导致频繁 Young GC

现象：某电商订单服务，JDK 11 + G1，堆 4GB。监控显示 Young GC 每分钟 20 次，平均停顿 8ms，P99 延迟 120ms（业务敏感）。

日志：

[10:00:01.000] GC(100) Pause Young 800M->600M(4096M) 7.8ms [10:00:03.500] GC(101) Pause Young 820M->610M(4096M) 8.1ms [10:00:06.000] GC(102) Pause Young 800M->600M(4096M) 7.5ms

诊断：每次 GC 间隔仅 2.5 秒，说明 Eden 很快填满。日志显示Eden regions: 30->0(30)，Region 8MB，Eden 总共 240MB——太小了。默认G1NewSizePercent=5（20%）下限被压低了。

调优：

# 扩大新生代下限，给 Eden 更多空间-XX:G1NewSizePercent=30-XX:G1MaxNewSizePercent=50

效果：Eden 涨到 1.2GB，Young GC 间隔延到 8 秒，次数降 70%，吞吐量从 92% 到 97%。

教训：G1 自适应有时会把新生代压太小（为达成停顿目标）。对延迟敏感场景，用G1NewSizePercent设下限。

案例2：内存泄漏导致频繁 Full GC

现象：某金融系统，JDK 8 + CMS，堆 8GB。运行 3 天后开始频繁 Full GC，每次 3-5 秒，服务卡顿。

日志：

[Day1] 老年代回收后 2GB [Day2] 老年代回收后 4GB [Day3] 老年代回收后 6GB → Concurrent Mode Failure → Full GC Serial Old

老年代回收后占用持续上升——典型的内存泄漏信号。正常情况下 GC 后老年代应该稳定在某个水位。

诊断：

1. 在 Full GC 频发时触发堆 dump：

   jcmd<pid>GC.heap_dump /tmp/heapdump.hprof

2. 用MAT（Memory Analyzer Tool）打开 dump。
3. 看 “Dominator Tree” 找最大对象。
4. 发现ConcurrentHashMap占 5GB，key 是String，内容是会话 ID——会话结束未清理。

调优：

• 修复代码：会话结束时map.remove(sessionId)。
• 临时缓解：加-XX:+ExplicitGCInvokesConcurrent让System.gc()走并发路径。

效果：修复后老年代稳定在 1.5GB，Full GC 消失。

教训：GC 后老年代持续上升 = 内存泄漏。用 MAT 分析 heap dump 是定位的标准流程。

案例3：G1 调优降低停顿

现象：某直播弹幕服务，JDK 11 + G1，堆 16GB。MaxGCPauseMillis 默认 200ms，但实测 P99 停顿 450ms，长尾请求超时。

日志分析：

[gc] GC(50) Pause Young 4000M->2000M(16384M) 180ms ← OK [gc] GC(55) Pause Young (Mixed) 8000M->5000M(16384M) 320ms ← 超标 [gc] GC(60) Pause Young (Mixed) 9000M->5500M(16384M) 480ms ← 严重超标

Mixed GC 停顿长——因为 CSet 太大（回收太多 Old Region）。

调优：

# 降低停顿目标-XX:MaxGCPauseMillis=100# Mixed GC 分更多次，每次少回收-XX:G1MixedGCCountTarget=16# 提早启动并发标记，避免 Mixed GC 堆积-XX:InitiatingHeapOccupancyPercent=35# 限制 Mixed GC 回收的 Old Region 比例-XX:G1OldCSetRegionThresholdPercent=5

效果：

• MaxGCPauseMillis 从 450ms 降到 120ms。
• Mixed GC 次数增加，但每次停顿可控。
• P99 延迟达标，吞吐量略降（98% → 97%），可接受。

教训：G1 的停顿目标需要和 CSet 大小配合。降停顿 = 减小 CSet = 增加回收频率。这是"停顿 vs 频率"的权衡。

生产环境参数推荐

通用 Web 服务（JDK 11/17，G1）

java-Xms4g-Xmx4g\-XX:+UseG1GC\-XX:MaxGCPauseMillis=200\-XX:InitiatingHeapOccupancyPercent=45\-XX:G1HeapRegionSize=8m\-XX:G1NewSizePercent=20\-XX:G1MaxNewSizePercent=50\-XX:G1MixedGCCountTarget=8\-XX:+ExplicitGCInvokesConcurrent\-XX:+ParallelRefProcEnabled\-XX:+UseContainerSupport\-XX:MaxRAMPercentage=75\-Xlog:gc*=info:file=/var/log/gc.log:time,uptime,level,tags:filecount=5,filesize=20m\-XX:+HeapDumpOnOutOfMemoryError\-XX:HeapDumpPath=/var/log/heapdump\-cpMyApp com.example.Main

低延迟服务（JDK 17+，ZGC）

java-Xms8g-Xmx8g\-XX:+UseZGC\-XX:MaxGCPauseMillis=10\-XX:+UseContainerSupport\-XX:MaxRAMPercentage=75\-Xlog:gc*=info:file=/var/log/gc.log:time,uptime,level,tags:filecount=5,filesize=20m\-XX:+HeapDumpOnOutOfMemoryError\-XX:HeapDumpPath=/var/log/heapdump\-cpMyApp com.example.Main

批处理（JDK 11/17，Parallel）

java-Xms8g-Xmx8g\-XX:+UseParallelGC\-XX:GCTimeRatio=19\-XX:MaxGCPauseMillis=500\-XX:+UseContainerSupport\-XX:MaxRAMPercentage=80\-Xlog:gc*=info:file=/var/log/gc.log:time,uptime,level,tags\-cpMyApp com.example.BatchJob

日志滚动配置

# 文件滚动：5 个文件，每个 20MB-Xlog:gc*=info:file=/var/log/gc.log:time,uptime,level,tags:filecount=5,filesize=20m

防止日志撑满磁盘，保留最近 100MB 日志够用于事后分析。

实践要点

1. 日志必开

生产环境必须开 GC 日志，开销极低（< 1% CPU）。没日志的 GC 问题等于盲调，事倍功半。

2. 建立基线

调优前先采集 24 小时正常 GC 日志，用 GCEasy 分析，记录吞吐量、停顿分布作为基线。任何调优都要和基线对比，避免"感觉变好"的自欺欺人。

3. 一次只改一个参数

# 错误：一次改 5 个参数-XX:MaxGCPauseMillis=100-XX:G1MixedGCCountTarget=16\-XX:InitiatingHeapOccupancyPercent=35-XX:G1NewSizePercent=30\-XX:G1OldCSetRegionThresholdPercent=5

改多个无法判断哪个有效。一次改一个，验证后再改下一个。

4. 压测验证

调优后必须用生产级负载压测验证。开发环境空载下 GC 表现好不代表生产也行。推荐 JMeter / Gatling 模拟真实流量。

5. 监控 Full GC

Full GC 次数是红线指标。正常情况下应为 0，一旦出现立即告警。生产中用 Prometheus 监控jvm_gc_pause_seconds_max并设告警阈值。

6. 容器内存限制

# 必须设，避免 JVM 误用宿主机内存-XX:+UseContainerSupport-XX:MaxRAMPercentage=75

JDK 10+ 默认开启容器感知，但仍需设MaxRAMPercentage限制堆占容器内存比例，留 25% 给堆外内存（Metaspace、线程栈、Direct Buffer）。

7. OOM 自动 dump

-XX:+HeapDumpOnOutOfMemoryError-XX:HeapDumpPath=/var/log/heapdump

OOM 时自动生成 heap dump，事后用 MAT 分析。生产事故的"黑匣子"。

小结

• GC 日志格式：JDK 8 用-XX:+PrintGCDetails（自由文本），JDK 9+ 用-Xlog:gc*=info（结构化统一日志），后者更易解析和过滤。
• 日志解读要点：看触发原因、回收前后内存、停顿时间、User/Real 比值（判断并行度）；Full GC 日志要重点分析触发原因和各阶段耗时。
• 分析工具：GCEasy（在线）、GCViewer（本地）、JMC（JDK 11+ 自带）、Prometheus（生产监控）。
• 调优案例：(1) 新生代太小→扩大 Eden；(2) 内存泄漏→MAT 分析 heap dump；(3) G1 停顿超标→减小 CSet、增加 Mixed GC 次数。
• 生产参数推荐：Web 服务用 G1 + 200ms 停顿目标；低延迟用 ZGC（JDK 17+）；批处理用 Parallel。必开 GC 日志滚动、OOM dump、容器内存限制。
• 调优方法论：建基线 → 一次改一参 → 压测验证 → 对比指标，形成闭环。

至此，垃圾回收模块从"如何判定对象存活"到"各款收集器原理"再到"日志解读与调优实战"已完整闭环。GC 调优没有银弹，理解原理 + 看懂日志 + 科学验证，才是稳定可靠的调优之道。

更多内容：JVM调优实战