jstat -gcutil 可实时监控 full gc 后老年代内存是否真实释放，关键看 ou 是否明显下降；若 ou 降幅极小或快速回升，则可能存在内存泄漏。
jstat -gcutil 是一个实用的实时监控命令，能帮你快速判断 full gc 后老年代（old）是否真正释放了内存，而不是“假回收”——即 gc 执行了，但 ou（old used）没下降或只降一点，说明对象还在被引用、可能有内存泄漏。
一、用 jstat -gcutil 看懂关键指标含义
执行命令：
jstat -gcutil <pid> 1000</pid>
每秒刷新一次，重点关注这几列：
- S0U / S1U：Survivor 0/1 区已使用空间（%），反映年轻代对象存活率
- EU：Eden 区使用率（%），飙升快说明对象创建频繁
- OU：Old 区使用率（%），这是判断 Full GC 效果的核心
- MU：Metaspace 使用率（%），持续上涨可能类加载泄漏
- YGC / FGC：Young 和 Full GC 次数
- YGCT / FGCT：对应 GC 总耗时（秒）
✅ 正常 Full GC 后，
OU应明显下降（比如从 95% → 30%）；
❌ 若OU下降极少（如 95% → 92%）、或很快又涨回，说明老年代对象无法被回收。
二、连续观察时关注的典型模式
用终端滚动查看，注意以下几种情况：
-
有效回收
- FGC 增加 1 次 → OU 从 88% 降到 25% → 随后缓慢回升（正常对象晋升）
- OU 回升速度平缓（如每分钟+0.5%），说明应用负载稳定、无泄漏
-
疑似泄漏
- FGC 后 OU 只降 2~3%，甚至不降
- OU 持续单向爬升（如 60% → 75% → 90% → OOM 前触发下一次 FGC）
- 同时
MU也在稳步上涨，需检查动态类加载（如热部署、Groovy 脚本、OSGi）
-
元空间干扰
-
MU接近 100% 且FGC频繁 → 可能因 Metaspace 耗尽触发 Full GC（即使堆还有空闲） - 解决方法：加
-XX:MaxMetaspaceSize=512m并观察MU是否趋于平稳
-
三、配合其他命令交叉验证
仅看 jstat -gcutil 不够，建议组合使用：
-
查进程 ID：
jps -l
-
确认是否真在做 Full GC（排除日志误读）：
jstat -gccause <pid> 1000</pid>
输出中
LGCC列会显示最近一次 Full GC 的原因，如Allocation Failure、Metadata GC Threshold、System.gc()等 -
快速看堆整体分布（容量 vs 使用量）：
jstat -gccapacity <pid> 1000</pid>
对比
OC（Old Capacity）和OU，算出绝对使用量（KB），比百分比更准——尤其当堆大小动态调整时 -
如果怀疑是
byte[]类型对象堆积（如网络缓冲区未释放）：jmap -histo <pid> | head -20</pid>
看
byte[]、char[]、java.util.HashMap$Node等是否排前三
四、一个小技巧：用 watch 实现高亮提醒
Linux 下可这样让 OU 异常时自动标红：
watch -n1 'jstat -gcutil <pid> | awk '\''NR==1{print} NR==2{if($5>90) printf "\033[1;31m%s\033[0m\n",$0; else print $0}'\'</pid>
当
OU（第5列）超过 90%，整行变红，一眼识别风险
不复杂但容易忽略
