GC日志分析是性能调优落地的第一环，需确保日志采集完整、聚焦三类关键信号、用jstat交叉验证、并反推代码根因，形成“现象→日志→行为→代码”闭环。
GC日志分析不是看一眼就完事的“检查动作”，而是性能调优真正落地的第一环。它把模糊的“卡、慢、抖”转化成可定位、可验证、可追踪的具体线索——比如某次P99延迟飙升，根源可能就是日志里一行 Full GC (Allocation Failure) 后跟着 2.5 秒停顿。
第一步：确保日志能采到、采得全
线上出问题时翻不出日志，等于医生没化验就开药方。必须在服务启动时就固化关键参数：
- -Xlog:gc*=info:file=gc.log:time,uptime,level,tags:filecount=10,filesize=10M（JDK10+ 推荐，结构清晰、字段丰富）
- 兼容老版本（如JDK8）用：-XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:+PrintGCTimeStamps -XX:+PrintHeapAtGC -XX:+PrintTenuringDistribution
- 务必加上 -XX:+PrintGCApplicationStoppedTime，它单独记录每次STW真实时长，比GC日志里的耗时更权威
- 日志路径建议用绝对路径，避免容器内相对路径失效；启用滚动（
filecount/filesize）防磁盘打满
第二步：盯住三类关键信号
不用通读全部日志，先扫这三处，80%的问题当场浮出水面：
-
频繁 Full GC：每分钟 ≥1 次，基本可判定老年代持续承压。重点查日志中
[Full GC (Allocation Failure)或[Full GC (Metadata GC Threshold)——前者是对象晋升失败，后者是元空间快满了 -
年轻代回收后 Survivor 区“塞不满”：日志里反复出现
Desired survivor size ... new threshold 2 (max 15)，说明对象存活率高、提前晋升，年轻代配置或代码逻辑可能有问题 -
单次 GC 停顿超阈值：YGC > 100ms 或 FGC > 500ms 就该警惕。结合
PrintGCApplicationStoppedTime看真实STW，若远大于日志标称值，可能是系统级干扰（如CPU争抢、内存页换入）
第三步：用 jstat 快速交叉验证
日志是“事后录像”，jstat 是“实时仪表盘”，两者对照才能排除误判：
- 执行 jstat -gcutil <pid> 1s 5，重点关注
O（老年代使用率）是否长期 >85%，FGC是否持续增长 - 如果
E（Eden）几乎始终为 0%，但YGC频次很高，说明对象“秒生秒死”，Eden 可能太小；反之若 Eden 长期 >95% 且 YGC 很少，说明分配速率低或对象生命周期长 - 对比
YGCT/FGCT占总运行时间比例：若 >5%，GC 已成明显瓶颈，需立即干预
第四步：从日志反推对象行为，直指代码根因
日志本身不解决问题，但它指向“谁在制造垃圾”。例如：
- 发现大量
char[]、byte[]出现在jmap -histo前几位，且和某接口强相关 → 检查该接口是否无节制拼接字符串、读取大文件未分块 - 日志显示老年代占用缓慢爬升，Full GC 后只回落一点点 → 怀疑静态集合缓存泄漏，用
jmap -dump+ MAT 分析 Retained Heap - Survivor 区年龄分布集中在 age=1，且
MaxTenuringThreshold被动态压到 2 → 说明大批对象活过一次 YGC 就晋升，大概率是短生命周期对象被意外长期引用（如线程局部缓存未清理）
不复杂但容易忽略：日志分析的价值不在“看懂每一行”，而在建立“现象→日志特征→内存行为→代码位置”的闭环。只要每次 GC 异常都走一遍这个链路，两三次之后，你就能从一行日志里大致猜出哪段代码在捣鬼。
