为什么 jmap -clstats 无法在 JDK 8u292+ 和 JDK 17+ 上正常工作

因为从 JDK 8u292 开始，jmap -clstats 被默认禁用；JDK 17+ 更是直接移除了该选项（JEP 366）。你执行时大概率会看到：java.lang.UnsupportedOperationException: clstats is not supported in this JVM。这不是权限或参数写错的问题，而是 HotSpot 团队主动废弃了这个统计口径——它底层依赖的内部 API 已不可靠，且结果常包含重复类加载器或漏计系统类加载器。

jmap -clstats 的替代方案：用 jstat -compiler + jstat -gcmetacapacity 拼出近似视图

虽然不能直接拿到“每个类加载器实例加载了多少类”，但你可以组合两个命令逼近核心关注点：类加载行为是否异常、元空间是否承压。

• jstat -compiler ：看 JIT 编译状态，间接反映类加载稳定性。若 failed 列持续增长，说明频繁动态生成/卸载类（如 Spring CGLIB、Groovy 脚本），可能连带引发类加载器泄漏
• jstat -gcmetacapacity ：重点关注 MC（当前元空间容量）、MU（已使用量）、CCSC/CCSU（压缩类空间），比 -clstats 更准确反映元空间真实水位
• 二者结合可判断：元空间占用高 + 编译失败多 → 很可能是大量匿名类或反射代理未被卸载，而非单纯“类太多”

真正要查“哪个类加载器占用了最多元空间”，得用 jmap -histo:live 配合堆转储分析

jmap -clstats 原本想回答的问题，其实本质是：有没有类加载器没被回收，还持有着大量类和静态字段？这必须落到对象引用链上才能确认。

• 先执行 jmap -dump:format=b,file=heap.hprof 获取实时堆快照
• 用 jhat heap.hprof 启动分析服务，或用 VisualVM / Eclipse MAT 打开，按 ClassLoader 类型筛选实例
• 重点观察：sun.misc.Launcher$AppClassLoader 通常只有一个；但若发现多个 org.springframework.boot.loader.LaunchedURLClassLoader 或自定义 URLClassLoader 实例且 loadedClassCount 持续上升，基本就是泄漏源头

JDK 21 下唯一保留的类加载器统计入口：jcmd VM.native_memory summary scale=MB

如果你用的是 JDK 21（或启用了 -XX:NativeMemoryTracking=summary 的较新版本），jcmd 可以给出更底层的视角：

• 输出中 [class] 行显示的是所有类元数据（含类加载器结构体本身）占用的本地内存总量，单位 MB
• 它不区分加载器实例，但能告诉你：这部分内存是否在持续增长（比如每小时涨 50MB），从而反推是否存在类加载器泄漏
• 注意：这个值 ≠ MetaspaceSize，它是 JVM 本地内存分配器的原始统计，更接近 OS 看到的真实开销

真正难定位的从来不是“有多少个类加载器”，而是“为什么某个加载器死活不被 GC”。这类问题必须结合堆转储里的 ClassLoader 实例及其 parent 引用、静态字段持有的对象图来追，jmap -clstats 早就不是那把钥匙了。