评估JVM垃圾回收器内存利用率需关注堆内存使用合理性：年轻代Eden区GC前后波动、老年代线性增长趋势及Full GC后剩余空间；晋升率、Survivor年龄分布与分配担保失败反映对象生命周期管理；元空间、代码缓存、直接内存等非堆区域须同步监控；结合jmap、jstat与详细GC日志定位真实瓶颈。
评估 JVM 垃圾回收器的内存利用率，核心是看堆内存是否被“有效使用”——既不能长期高水位运行导致频繁 GC，也不能过度预留造成资源浪费。关键不在于“用了多少”，而在于“用得是否合理、稳定、可持续”。
看堆内存使用率的波动趋势
单纯一个瞬时百分比（比如 75%）意义有限。重点观察：
- 年轻代 Eden 区在 Minor GC 前是否稳定接近 100%，GC 后是否快速回落至 10%~30% —— 这反映分配速率与回收节奏匹配；
- 老年代使用率是否缓慢、线性上升，还是突然跳升或反复震荡 —— 突然跳升可能有大对象直接入老年代或内存泄漏；
- Full GC 后老年代剩余空间是否仍高于 30%，若常低于 10%，说明老年代实际承载能力已逼近极限。
结合对象晋升行为分析
内存利用率高低，和对象从年轻代“晋升”到老年代的效率密切相关：
- 通过 GC 日志检查 Promotion Rate（晋升率）：长期高于 20%~30%，说明大量对象没在年轻代“自然死亡”，过早挤占老年代空间；
- 观察 Survivor 区的“幸存者年龄分布”：若大量对象在 S0/S1 间复制 3~4 次就晋升，可能 Survivor 空间偏小或 MaxTenuringThreshold 设置过低；
- 留意是否频繁触发“空间分配担保失败”，这说明老年代虽未满，但碎片化或剩余空间不足以容纳一次 Minor GC 的晋升总量。
关注非堆内存与元空间占用
堆内存只是 JVM 内存的一部分，忽略非堆区域会导致整体利用率误判：
- 元空间（Metaspace）持续增长且未触发回收，可能是动态生成类过多（如反射、CGLIB、热部署），占用真实内存却不算在堆里；
- 代码缓存（CodeCache）接近上限会禁用 JIT 编译，间接增加解释执行开销，影响吞吐量；
- 直接内存（Direct Buffer）由 -XX:MaxDirectMemorySize 控制，若应用大量使用 NIO，需单独监控其使用量，避免 OOM 而堆内存尚宽松。
用工具验证实际压力点
不要只依赖 jstat 的平均值，要定位真实瓶颈：
- 用 jmap -histo:live 查看存活对象类型和数量，确认是否某类业务对象（如 DTO、缓存 Entry）异常堆积；
- 用 jstat -gc <pid> 关注 YGC/FGC 次数、耗时及每次回收释放的内存量，计算“单位时间释放内存”是否匹配业务负载；
- 开启详细 GC 日志（-Xlog:gc*,gc+heap=debug）后，注意 “PSYoungGen” 和 “ParOldGen” 各自的使用峰值与回收后剩余，区分问题发生在哪一代。
