jstat可快速查看jvm实时状态，无需额外配置；需先用jps -l获取pid，再结合-gcutil、-gc、-gccause等选项监控gc、内存及类加载行为，并通过时间间隔、表头刷新和趋势分析判断性能问题。
直接用 jstat 就能快速查看 JVM 实时状态，它不依赖额外配置，命令敲完几秒内就出数据，适合开发调试和线上巡检。
先拿到 Java 进程 ID
没 PID 就没法监控，得先查：
- 运行
jps -l，列出所有 Java 进程及其完整主类名（比如 Spring Boot 应用会显示JarLauncher） - 如果进程多、不好分辨，加
-m看启动参数，或-v看 JVM 参数（含-Xmx等），帮助确认目标进程 - 注意：某些环境可能禁用了性能数据采集（
-XX:-UsePerfData），这时 jstat 会报错；默认是开启的，一般无需干预
常用监控选项与关键指标
选对选项才能看到真正有用的信息：
-
jstat -gcutil <pid></pid>：看 GC 效率，重点关注 S0/S1（Survivor 使用率）、E（Eden）、O（老年代）、M（元空间） 的百分比。持续接近 100% 说明对应区域快满了 -
jstat -gc <pid></pid>：看原始数值，如 YGC（Young GC 次数）、YGCT（Young GC 总耗时）、FGC（Full GC 次数）、FGCT（Full GC 总耗时）。FGC 频繁或 FGCT 占比高，往往是内存泄漏或堆配置不合理信号 -
jstat -gccause <pid></pid>：比-gcutil多一列 LGCC（Last GC Cause），告诉你最近一次 GC 是因为什么触发的（如Allocation Failure或Metadata GC Threshold），便于定位根因 -
jstat -class <pid></pid>：检查类加载行为，loaded（已加载类数）持续上涨且 unload 很少，可能是动态类生成未清理，引发元空间溢出
带节奏的实时观察
单次输出意义有限，要看出趋势才有效：
- 加时间间隔和次数，例如：
jstat -gcutil 12345 2000 5表示每 2 秒输出一次，共 5 次 - 加
-t显示进程已运行秒数，方便对照 GC 时间（GCT）占比：若 GCT / 运行时间 > 20%，说明 GC 开始影响吞吐；超过 50% 就该排查了 - 加
-h 3每 3 行输出一次表头，避免滚动后看错列名
怎么看才算“有问题”
不能只盯数字，要结合变化节奏判断：
- 老年代使用率（O 列）缓慢但持续上升，且 FGC 次数同步增加 → 可能存在对象长期存活或内存泄漏
- Eden 区（E 列）每次 GC 后回收不干净，Survivor 区（S0/S1）使用率居高不下 → 可能 SurvivorRatio 设置不合理，或对象晋升过快
- 元空间（M 列）持续增长、频繁 GC → 检查是否大量使用反射、动态代理或字节码生成框架（如 CGLIB、ByteBuddy）
- YGC 耗时（YGCT）单次明显变长（比如从 20ms 增到 100ms+）→ 新生代可能碎片化严重，或对象分配速率突增
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
