通过分析gc日志可客观评估调优效果，需聚焦停顿频率、持续时间、内存回收效率、晋升压力四维度协同优化，并确保日志开启且信息完整；jdk 11+推荐-xlog:gc*:file=gc.log:time,uptime,level,tags，jdk 8需配置printgcdetails等参数；须启用printadaptivesizepolicy观察动态调优；应采集稳定期日志，关注young gc频率与耗时、old/mixed gc缓解情况、对象晋升健康度、元空间与直接内存泄漏；警惕伪优化：如maxgcpausemillis过低引发mixed gc激增、盲目扩堆延长暂停、关闭字符串去重致老年代暴增；建议用gcviewer、gceasy.io或awk脚本辅助定量分析。
通过分析 GC 日志，可以客观判断调优是否真正改善了垃圾回收行为——关键不是看“停顿变短了”，而是看 停顿频率、持续时间、内存回收效率、晋升压力 这四个维度是否协同优化。
确认日志是否开启且信息完整
没有高质量日志，评估就是空谈。需确保 JVM 启动参数包含以下基础组合：
- -Xlog:gc*:file=gc.log:time,uptime,level,tags（JDK 11+ 推荐，结构清晰、标签丰富）
- 若用 JDK 8，用 -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -Xloggc:gc.log -XX:+UseGCLogFileRotation -XX:NumberOfGCLogFiles=5 -XX:GCLogFileSize=10M
- 务必启用 -XX:+PrintAdaptiveSizePolicy（尤其对 G1/Parallel），观察 JVM 是否动态调整堆各区域大小
聚焦四类核心指标看趋势变化
调优前后对比不能只截取单次 GC，应采集稳定运行期（如 Full GC 后连续 30 分钟）的日志，关注以下指标的统计趋势：
- Young GC 频率与耗时：单位时间内次数是否下降？平均 Pause 时间是否更稳定？例如从每 2 秒一次降到每 5 秒一次，且 P99 停顿从 45ms 降至 28ms
- Old GC / Mixed GC 触发条件是否缓解：老年代使用率峰值是否降低？Mixed GC 的 Region 数是否减少？G1 中 [G1 Evacuation Pause] 后是否还频繁跟 [G1 Remark] 或 [Full GC]
- 对象晋升行为是否健康：日志中 "tenured:" 或 "to-space exhausted" 出现次数是否显著减少？Survivor 区 "age" 分布是否更集中（说明短期对象没乱飘）
- 元空间与直接内存是否隐性泄漏：检查 "Metaspace" 使用量是否持续缓慢上涨；"Direct buffer memory" 是否在 GC 后不回落
识别典型“伪优化”陷阱
有些调优看似参数更“激进”，实则掩盖问题或引发新瓶颈：
- 把 -XX:MaxGCPauseMillis 设得过低（如 50ms），导致 G1 频繁触发 Mixed GC，吞吐量骤降——此时日志中会看到大量小而密的 Mixed 暂停，但应用 RT 反而升高
- 盲目增大堆（如从 4G 到 16G），Young GC 时间变长、Old GC 更难避免——日志里 "GC pause (G1 Evacuation Pause) (young)" 耗时从 30ms 升至 90ms，且 Full GC 仍每月一次
- 关闭 -XX:+UseStringDeduplication 后，日志中 "String Deduplication" 行消失，但老年代存活对象暴增——说明重复字符串本就是大头，不该关
用工具辅助定量比对
人工扫日志易遗漏模式，建议配合轻量工具提升效率：
- GCViewer：拖入 gc.log 自动生成吞吐量、暂停分布直方图，支持多文件横向对比（调优前 vs 调优后）
- gceasy.io（在线）：自动识别 GC 类型、计算 Promotion Rate、Allocation Rate，标出“高风险项”如 “High Old Gen Allocation Rate”
- 自定义脚本（如 awk/grep）提取关键字段：awk '/Pause/ {sum+=$6; n++} END {print "avg:", sum/n}' gc.log
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
