如何评估 JVM 垃圾回收器的内存利用率

评估 JVM 垃圾回收器的内存利用率，说到底就是看堆内存到底用得是否“靠谱”。既不能水平太高、搞得 GC 频繁到让人头疼，也不能预留太多、白白浪费资源。关键不是看“用了多少”，而是看“用得是否合理、稳定、可持续”。很多团队盯着一个瞬时的 75% 就慌了，其实意义有限——得看趋势、看行为、看背后真正发生了什么。 先说说堆内存使用率的波动趋势。年轻代 Eden 区在 Minor GC 前能不能稳定接近 100%，GC 后能不能快速回到 10%~30%？这直接反映了分配速率和回收节奏是否匹配。老年代的使用率如果是缓慢线性上升，那是正常老化；但如果突然跳升或者反复震荡，那就要警惕了——要么有大对象直接进入老年代，要么就是内存泄漏的信号。另外，Full GC 后老年代剩余空间如果还有 30% 以上，还算安全；要是经常低于 10%，说明老年代的承载能力已经逼近极限了。 再看看对象晋升行为。内存利用率高不高，和对象从年轻代“晋升”到老年代的效率密切相关。通过 GC 日志检查 Promotion Rate，长期高于 20%~30% 就说明大量对象没能在年轻代“自然死亡”，而是过早挤占了老年代的空间。再观察 Survivor 区的幸存者年龄分布：如果大量对象在 S0/S1 之间复制个三四次就晋升了，那可能 Survivor 空间偏小，或者 MaxTenuringThreshold 设置得太低。还有一个很容易被忽略的点——是不是频繁触发“空间分配担保失败”？这意味着老年代虽然还没满，但碎片化严重，或者剩余空间根本不够容纳一次 Minor GC 要晋升的总量，这就非常危险了。 别忘了非堆内存和元空间。堆内存只是 JVM 内存的一部分，忽略非堆区域会导致整体利用率误判。元空间如果持续增长且从不触发回收，可能是你的应用在动态生成大量类（比如反射、CGLIB、热部署），这部分占用的是真实内存，却不算在堆里，很容易造成误解。代码缓存接近上限时，JIT 编译会被禁用，解释执行的开销就会上来，间接影响吞吐量。直接内存由 `-XX:MaxDirectMemorySize` 控制，如果应用大量使用 NIO，那就要单独监控直接内存的使用量，否则堆内存还很宽松，直接内存却先 OOM 了。 最后，验证实际压力点的时候，别只依赖 `jstat` 的平均值。用 `jmap -histo:live` 看看存活对象的类型和数量，确认是不是某类业务对象（比如 DTO、缓存 Entry）在异常堆积。用 `jstat -gc ` 关注 YGC/FGC 的次数、耗时以及每次回收释放的内存量，算一算“单位时间释放内存”是不是和业务负载匹配。开启详细 GC 日志（`-Xlog:gc*,gc+heap=debug`）后，关注 `PSYoungGen` 和 `ParOldGen` 各自的使用峰值和回收后剩余，才能准确判断问题究竟出在年轻代还是老年代。