jvm垃圾回收统计分析需通过gc日志和jstat指标识别回收频率、停顿时间、内存分布及异常模式；重点关注gc类型、real耗时、内存变化、回收效果，结合gcviewer等工具定位瓶颈。
分析 JVM 垃圾回收统计信息，核心是读懂 GC 日志和运行时指标，从中识别回收频率、停顿时间、内存分布与异常模式。不依赖猜测，靠数据定位真实瓶颈。
关键统计项怎么看
GC 日志中几个字段直接反映健康状况：
-
GC 类型：
GC（Young GC）、Full GC或G1 Evacuation Pause等，区分新生代回收、混合回收还是全局回收；频繁 Full GC 是严重信号 -
耗时：
[Times: user=..., sys=..., real=...]中的real时间即 STW（Stop-The-World）实际暂停毫秒数，超过 200ms 需关注 -
内存变化：如
[Eden: 120M->0M(128M), From: 15M->18M(16M), To: 0M->16M(16M), Tenured: 320M->342M(1024M)]，能看出对象晋升量、 Survivor 区是否溢出、老年代增长趋势 -
回收效果：对比 GC 前后堆使用量，例如
heap: 450M->180M(2048M)，若回收后仍接近上限，说明内存压力持续或存在泄漏
用 jstat 实时抓取核心指标
无需重启应用，命令行即可获取当前 GC 统计：
-
jstat -gc <pid> 1s</pid>每秒刷新一次，重点关注列：YGCT（Young GC 总耗时）、FGCT（Full GC 总耗时）、YGC（Young GC 次数）、FGC（Full GC 次数）、EU（Eden 使用量）、OU（老年代使用量） - 若
FGC在短时间内持续上升，或OU接近OC（老年代容量），大概率存在内存泄漏或晋升过快 - 观察
YGC频率：每秒多次 Young GC 通常意味着 Eden 太小或对象生命周期短但分配速率过高
识别典型异常模式
统计不是罗列数字，而是发现“不对劲”的组合：
-
晋升失败（Promotion Failure）：日志中出现
to-space overflow或Promotion Failed，说明 Survivor 区不足以容纳存活对象，大量对象被迫直接进入老年代，易触发 Full GC - 并发模式失败（Concurrent Mode Failure）（CMS 已弃用，但历史系统仍见）：老年代在并发标记未完成时被填满，被迫退化为 Serial Old 的 Full GC，停顿极长
- G1 的 Mixed GC 频繁且无效：Mixed GC 后老年代使用量未明显下降，说明回收效率低，可能因 Region 碎片化严重或大对象未被及时处理
-
ZGC/Shenandoah 的
Load Average异常升高：虽停顿极短，但后台 GC 线程长期高负载，往往提示应用分配速率远超回收能力
辅助工具推荐
人工看日志容易遗漏细节，建议搭配工具提升效率：
- GCViewer：免费开源，拖入 GC 日志即可生成图表，直观显示 GC 频率、停顿分布、堆使用趋势
- GCEasy：在线分析，自动标注问题（如 “High Frequency Young GC”、“Memory Leak Suspected”），附带优化建议
- JFR（Java Flight Recorder）：JDK 自带，可开启长时间低开销录制，结合 GC 事件、内存池、线程堆栈，做根因分析
