JDKjstat命令使用与GC监控详解

jstat 是 JVM 实时监控的“透视镜”，虽不生成日志也不抓堆快照，却能以极轻量方式精准暴露类加载泄漏（如 loaded 持续上涨而 unloaded 几乎为 0）和 GC 压力异常（如 Eden 长期超 95% 暗示 Young GC 频繁，Old 接近 100% 伴 FGC 增多则预警老年代危机），配合 -class、-gcutil 等参数组合与合理采样节奏，再结合 JDK 版本差异辨析字段含义，你就能在服务尚在运行时快速定位性能隐患根源——不是等崩溃才行动，而是让问题在萌芽中浮现。

怎么用 jstat 快速查出类加载异常或 GC 频繁问题

jstat 不是日志分析器，也不是堆快照工具，它只做一件事：在进程活着的时候，实时抓取 JVM 内部的统计快照。想看出类是否在疯狂加载（比如 Spring 动态代理、字节码生成框架引发的泄漏），或者 Young GC 每秒来好几次，就得盯住几个关键字段，而不是扫一眼就划走。

• jstat -class 看 loaded 和 unloaded：如果 loaded 持续上涨且 unloaded 基本为 0，大概率有类加载器没被回收（比如 Web 应用热部署后旧 ClassLoader 还挂着）
• jstat -gcutil 1000 5 每秒采一次、共 5 次，重点看 E（Eden 使用率）和 O（Old 使用率）：若 E 总在 95% 以上反复横跳，说明对象“活不过一轮 Young GC”，可能对象太大直接进老年代，或 Survivor 区太小导致提前晋升
• 别只跑一次——jstat 单次输出是瞬时值，没有上下文。必须带 interval 和 count（或手动 Ctrl+C 中断），否则看不出趋势

-gc 和 -gcutil 到底该用哪个

二者数据来源完全一样，只是单位不同：-gc 输出 KB，-gcutil 输出百分比。选哪个，取决于你当前要回答的问题。

• 查内存是否真溢出？用 -gcutil：一眼看到 O 到了 98%，比看 OU=28416.0 和 OC=28672.0 快得多
• 调参时验证扩容效果？用 -gc：比如加了 -Xmn256m 后，对比 EC 字段是否从 2048.0 变成 262144.0（即 256MB），避免被百分比“平滑掉”实际容量变化
• JDK 8+ 注意 M（Metaspace）和 CCS（Compressed Class Space）：它们不会出现在老版本的 -gcutil 里，但一旦 M 接近 100% 且 FGC 开始上升，就是元空间不足，不是堆内存的事

为什么 jstat -compiler 很少有人用，但它能帮你定位 JIT 失效

多数人忽略这个选项，是因为应用启动后 JIT 编译基本就完成了。但在某些场景下，它的输出是唯一线索。

• 看到 failed 列非零？说明方法被 JIT 编译失败过，常见于：使用了不支持的 JVM TI agent、开启了过于激进的编译阈值（-XX:CompileThreshold）、或代码里有非法字节码（如 ASM 改写出错）
• compiled 数量长期停滞不动？可能整个应用都卡在解释执行模式，比如用了 -Xint（纯解释模式）却没意识到，或容器环境 CPU 资源受限导致 JIT 线程饿死
• 注意：jstat -compiler 不显示具体哪些方法没编译，它只告诉你“有事发生”。真要深挖，得切到 -XX:+PrintCompilation 或用 JFR

容易被忽略的兼容性坑：JDK 版本一升级，jstat 字段就对不上

JDK 7 到 JDK 17，jstat 的输出字段增减、重命名、含义调整至少有三次。不是所有文档都及时更新，抄老教程很容易看错列。

• JDK 7 及以前有 PGC/PGCT（Permanent GC），JDK 8+ 全换成 MC/MU（Metaspace）和 CCSC/CCSU
• jstat -gccause 在 JDK 9+ 才稳定输出 lgcc（last gc cause），早期版本可能为空或格式混乱
• 最稳妥的方式：先运行 jstat -options，确认当前 JDK 支持哪些参数；再用 jstat -gc 看首行字段名，以实际输出为准，别信记忆或截图

字段含义会变，但核心逻辑不变：Eden 满了就 Young GC，Old 涨太快就查对象生命周期，Loaded 类一直增就查 ClassLoader 引用链。工具只是镜子，照得清不清，取决于你盯着哪块玻璃看。

以上就是《JDKjstat命令使用与GC监控详解》的详细内容，更多关于的资料请关注golang学习网公众号！