怎么分析 JVM 的 MetaSpace 堆外泄露排查：通过 jcmd VM.metaspace 追踪类元数据

直接看 jcmd VM.metaspace 输出是否可信

答案是：不可信。这里有个常见的理解误区。这个命令展示的，仅仅是当前已加载类的元数据内存用量。它看不见那些已经卸载、但还没被 Metaspace 内部回收的“残留块”，更统计不到 Native 层通过 mmap 分配、却未归还给 Metaspace 管理的内存。所以，你看到 used 显示 256MB、committed 显示 384MB，并不代表真实的堆外内存增长就到此为止了。

一个典型的误判场景是：MetaspaceSize 参数设置得太小（比如沿用默认的 21807104 字节，约 20.8MB），导致频繁触发扩容和内存碎片化。这时 jcmd 可能会显示 committed 持续上涨，但 used 却基本不动——这其实是 Metaspace 自身的管理开销在增加，并非真正的内存泄漏，却很容易被当成问题的根源。

jcmd VM.metaspace 要结合 -XX:NativeMemoryTracking=detail 一起用

单独运行 jcmd pid VM.metaspace，视野是受限的。它只能看到类元数据这一层的汇总情况，无法透视底层内存是通过 mmap 还是 brk 分配的，也无从知晓 ClassLoader 是否因为被引用而无法卸载。

正确的做法是：

• 务必加上 JVM 参数：-XX:NativeMemoryTracking=detail，然后重启应用。
• 再执行命令：jcmd pid VM.native_memory summary scale=MB，重点关注 Metaspace 和 Internal 这两栏。
• 如果发现 Metaspace 栏增长缓慢，但 Internal 栏却在持续上涨（尤其是伴随着大量 64MB 大小的匿名映射出现），那基本可以排除纯 Ja va 类加载导致的泄漏，问题很可能指向了 Native 层，比如 JNI 调用、Netty 的 Unsafe 操作，或者某些 JDBC 驱动。

查 Metaspace 泄漏，真正要盯的是 ClassLoader 生命周期

这里有个核心逻辑需要厘清：Metaspace 本身并不会“泄漏”，真正会“泄漏”的，是那些无法被垃圾回收（GC）的 ClassLoader。只要一个 ClassLoader 还活着，由它加载的所有类的元数据就会一直占据着 Metaspace 的空间。

导致 ClassLoader 无法回收的典型原因有哪些呢？

• Web 应用热部署时，旧的 WebAppClassLoader 被新实例替换，但线程池、定时任务或某些静态缓存里，还残留着对旧 loader 的引用。
• 代码中使用了 ThreadLocal 或缓存了 Class.forName(“xxx”) 返回的 Class 对象，并且没有及时清理。
• 某些第三方 SDK（比如一些老版本的 Druid、Logback）在 shutdown 时，没有正确释放其内部的 ClassLoader。

如何验证？可以使用 jcmd pid VM.class_hierarchy -all 来查看活跃的 ClassLoader 数量；或者，对堆内存进行 dump，然后用 MAT 等工具检查 ja va.lang.ClassLoader 的实例数量，看它是否随着请求量增加而线性增长。

pmap -x 和 /proc//smaps 是绕过 JVM 层的底线手段

当 jcmd VM.metaspace 和 native_memory 都显示一切正常，但物理内存（RSS）却持续上涨时，就必须跳出 JVM 的视角，直接去操作系统层面检查内存映射了。

需要关注的关键信号包括：

• 执行 pmap -x | grep “64M\|128M”，如果出现大量相同大小的匿名映射（anon），并且这些地址段不在 jcmd VM.native_memory 的报告范围内，那就非常可疑。
• 运行命令 grep -i “mmap” /proc//smaps | awk ‘{sum += $2} END {print sum/1024/1024 “ GB”}’，如果计算结果远超过 jcmd 中 Internal + Metaspace 的总和，也说明有“账外”内存。
• 这类内存通常来源于 Netty 的 PooledByteBufAllocator、JDBC 驱动的 native buffer，或者自定义的 JNI 库——它们完全游离于 Metaspace 的管理体系之外。

说到底，Metaspace 只管类的定义信息，管不了字节码加载器背后的 native buffer、direct memory，甚至是 mmap 文件映射。真要定位到根因，得从这些 64MB 内存块所在的 mmapped file 或 heap 标签反推调用栈，而不是一直盯着 VM.metaspace 的输出反复刷新。这才是关键所在。