jvm堆内存垃圾回收分析核心在于判断gc行为健康性：关注minor gc频率与耗时、老年代压力与full gc诱因、gc日志中的对象生命周期特征，并结合jstat、jmap、mat等工具定位真实瓶颈。
堆内存的垃圾回收分析是JVM性能监控的核心环节，关键不在于看GC是否发生，而在于判断GC行为是否健康——频率是否合理、停顿是否可控、对象晋升是否异常、内存使用趋势是否稳定。
关注 Minor GC 的频率与耗时
新生代GC（Minor GC）本应高频但轻量。若发现：
- Eden区每次几乎满才触发，但GC后Survivor区迅速填满 → 可能 SurvivorRatio 设置不合理，或对象存活率偏高；
- Minor GC 频率陡增（如每秒多次），且 Eden 区回收后剩余空间持续偏低 → 很可能有短生命周期对象暴增，或存在隐式对象缓存（如日志上下文、临时集合未清理）；
- 单次 Minor GC 耗时超过 50ms（尤其在 CMS 或 G1 下）→ 需检查是否有大对象直接进入老年代，或 Survivor 区中大量对象年龄增长过快。
识别老年代压力与 Full GC 诱因
Full GC 是性能劣化的重要信号，多数源于老年代空间不足。常见线索包括：
- Minor GC 后大量对象直接晋升至老年代（观察 GC 日志中的 “promoted” 字段）→ 可能 Survivor 空间过小，或 -XX:MaxTenuringThreshold 设置过低；
- 老年代使用率缓慢但持续上升，且 Minor GC 无法释放 → 检查是否存在强引用泄漏（如静态 Map 缓存未清理、ThreadLocal 未 remove）；
- Full GC 前老年代已接近 95%，但 GC 后仅小幅下降 → 表明存在顽固不可回收对象，需用 jmap + MAT 分析直方图与支配树。
结合 GC 日志看对象生命周期特征
启用 -Xlog:gc*:file=gc.log:time,uptime,level,tags（JDK 9+）后，重点关注：
- Age distribution：显示各年龄对象数量。若年龄 1 的对象占比极高，说明多数对象熬过一次 GC 就“变老”，可能 Eden 太小或分配速率过高；
- Tenuring threshold：实际使用的晋升阈值。若频繁低于设定值（如设为 15，实际多为 2~4），说明 Survivor 空间不足以容纳存活对象，触发提前晋升；
- Metaspace 和 CodeHeap 使用情况：虽非堆内存，但其持续增长常伴随 Full GC，提示类加载泄漏或 JIT 编译器压力。
用工具定位真实瓶颈点
日志只反映现象，需工具交叉验证：
- jstat -gc
实时查看各代容量、已用、GC 次数与耗时，适合快速巡检； - jmap -histo:live
统计堆中实例数量及占用，快速发现异常类型（如 HashMap$Node 过多暗示缓存滥用）； - MAT 打开 heap dump 后，按“Leak Suspects”报告初筛，再用“Dominator Tree”聚焦大对象及其引用链，避免被表象误导。
