真正影响服务响应的往往是单次GC停顿时间、内存分配速率、对象晋升行为等静默指标；需关注GC日志中real耗时、jstat计算的平均单次YGC时间、Allocation Failure原因及JDK版本对应日志参数配置。
别只盯着 YGC 次数和有没有 FGC —— 这是最容易掉进去的坑。真正影响服务响应的，往往是单次停顿时间、内存分配速率、对象晋升行为这些“静默指标”，它们在日志里有迹可循，但需要主动识别。
误区一：把“没 Full GC”当健康信号
很多故障现场显示 FGC=0，YGC 频率也看似正常，但接口 RT 却周期性飙升。这是因为 G1 或 ZGC 在并发阶段虽不 STW，但 Evacuation Pause（如 G1 Evacuation Pause (young)）仍会暂停应用线程。这类 pause 在日志中明确标注为 “pause”，耗时若持续 >50ms，就足以引发卡顿。关键要看日志里的 secs 字段，而不是只扫一眼 FGC 计数器。
- 重点关注每条 GC 日志末尾的耗时，例如
0.1501230 secs - 用
jstat -gc <pid> 1s实时比对 YGCT / YGC，算出平均单次耗时：YGCT ÷ YGC - 若平均 >20ms 且波动大，说明年轻代空间或对象生命周期配置不合理
误区二：忽略 GC 触发原因，只看结果
日志里反复出现 (Allocation Failure)，不代表只是“内存不够用了”。它背后可能是：短期对象暴增（如接口批量解析 JSON）、大对象直接入老年代（触发 Humongous Allocation）、甚至 元空间不足导致类加载失败继而引发 GC。不同原因对应完全不同的调优路径。
- 看到
(Allocation Failure)，先查 Eden 区使用率是否总在 GC 前后快速打满（用 jstat 的 E 列） - 看到
(G1 Humongous Allocation)，说明有对象 > G1HeapRegionSize（默认 2MB），需检查是否有未分片的大集合、缓存或临时字节数组 - 若同时伴随 Metaspace 使用率攀升，要排查动态生成类（如 CGLIB、JSON 序列化框架）或类加载器泄漏
误区三：用错日志参数，误判“无日志=无 GC”
监控显示 jvm.gc.pause.counter 持续上涨，但 gc.log 一片空白——这不一定是 JVM 没干活，很可能是日志开关没开对。JDK 9+ 后 -XX:+PrintGCDetails 已废弃，仅靠它不会输出任何内容；G1/ZGC 还需显式开启对应标签，比如 -Xlog:gc+pause=debug 才记 pause 事件。
- JDK 8：必须配齐
-XX:+PrintGCDetails -XX:+PrintGCDateStamps -Xloggc:gc.log - JDK 11+：推荐统一用
-Xlog:gc*:file=gc.log:time,uptime,level,tags:filecount=5,filesize=10M - 特别注意：某些 APM agent（如 SkyWalking）会通过 JVMTI 注入计数，此时
jvm.gc.pause.counter增长 ≠ JVM 真实发生了 GC，需交叉验证jvm.memory.used和堆趋势
误区四：脱离业务上下文读日志
GC 日志不是孤立存在的。一次看似普通的 Young GC，如果发生在支付回调高峰期，且紧随 System.currentTimeMillis() 调用之后，可能暴露的是业务代码中高频创建 SimpleDateFormat 等非线程安全对象的问题；某次 Full GC 若总在每天 02:00 出现，大概率关联着定时任务刷全量缓存。
- 把 GC 时间戳和业务日志、定时任务调度记录、流量监控曲线对齐
- 关注 GC 前后是否有明显对象突增：用
jmap -histo <pid>抓快照对比 - 若 GC 耗时与 CPU 使用率峰值严格同步，优先怀疑是 GC 线程本身在抢资源，而非业务线程问题
