用jstat快速定位类加载异常或gc频繁问题：通过jstat -class 观察loaded持续上升且unloaded≈0，判断classloader泄漏；用jstat -gcutil 1000 5监控e/o使用率波动，e长期>95%预示young gc频繁，o接近100%伴fgc增多则提示老年代压力大。
怎么用 jstat 快速查出类加载异常或 GC 频繁问题
jstat 不是日志分析器，也不是堆快照工具，它只做一件事：在进程活着的时候，实时抓取 JVM 内部的统计快照。想看出类是否在疯狂加载（比如 Spring 动态代理、字节码生成框架引发的泄漏），或者 Young GC 每秒来好几次，就得盯住几个关键字段，而不是扫一眼就划走。
-
jstat -class <pid></pid>看loaded和unloaded：如果loaded持续上涨且unloaded基本为 0，大概率有类加载器没被回收（比如 Web 应用热部署后旧 ClassLoader 还挂着） -
jstat -gcutil <pid> 1000 5</pid>每秒采一次、共 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 <pid></pid>看首行字段名，以实际输出为准，别信记忆或截图
字段含义会变，但核心逻辑不变：Eden 满了就 Young GC，Old 涨太快就查对象生命周期，Loaded 类一直增就查 ClassLoader 引用链。工具只是镜子，照得清不清，取决于你盯着哪块玻璃看。
