jstat命令可实时监控JVM内存回收状态，无需插件、改代码或重启服务；通过-jps查PID，用-gc看GC频率与耗时，-gcutil观察内存使用趋势，-gccause定位GC触发原因。

直接用 jstat 命令就能实时看 JVM 内存回收状态，不用装插件、不改代码、不重启服务。关键在选对选项、盯住几列数字，问题基本一眼可判。

先拿到 Java 进程 PID

运行以下命令查目标进程号：

• jps -l —— 推荐，输出带完整主类或 JAR 路径，不易混淆
• 或 ps aux | grep java —— 查启动参数辅助确认，避免监控错实例

用 -gc 看 GC 频率与耗时（最常用）

执行：jstat -gc <pid> 1000 5（每秒刷新一次，共 5 行）

重点关注这几列：

立即学习“Java免费学习笔记（深入）”；

Comprehensive Three.js 3D graphics reference

详细的 Three.js 3D 图形参考，涵盖场景设置、相机、几何体、材质、光照、动画、控制器、加载器、数学工具和调试。

下载

• YGC / YGCT：年轻代 GC 次数和总耗时（秒）。YGC 超过 10 次/秒，或单次 YGCT > 50ms，说明 Eden 区偏小或对象存活时间异常延长
• FGC / FGCT：Full GC 次数和总耗时。只要 FGC 数值在增长，就必须立刻排查——常见原因包括元空间打满、大对象直入老年代、CMS 失败兜底等
• GCT：所有 GC 总耗时。除以应用运行总时间，即得 GC 吞吐量；低于 95% 就算异常，影响响应稳定性

用 -gcutil 看内存使用趋势（更直观）

执行：jstat -gcutil <pid> 2000（每 2 秒输出一行百分比）

盯住这三列变化：

• E（Eden）：持续接近 100% 且不回落 → 分配速率高，或 Survivor 区太小导致对象提前晋升到老年代
• O（老年代）：缓慢但稳定上升 + FGC 同步增加 → 典型老年代内存泄漏信号，建议配合 jmap -histo 查长生命周期对象
• M（元空间）：持续上涨，且 unloaded 类数几乎为 0 → 类加载器未释放，常见于 Spring Boot DevTools、MyBatis Mapper 动态代理场景

用 -gccause 定位每次 GC 的真实原因

执行：jstat -gccause <pid> 1000（每秒输出，含触发原因）

看 “LGCC” 列内容，比单纯数次数更有诊断价值：

• Allocation Failure：Eden 区满了——最常见，但如果高频出现，说明新生代配置不合理
• Metadata GC Threshold：元空间达到阈值——该调 -XX:MaxMetaspaceSize 或查类泄漏
• System.gc()：代码里写了显式 GC 调用——生产环境应禁用 -XX:+DisableExplicitGC