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

首页

编程语言

热心网友

转载

2026-04-28

怎么分析 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 的输出反复刷新。这才是关键所在。

来源:https://www.php.cn/faq/2382890.html

免责声明：游乐网为非赢利性网站，所展示的游戏/软件/文章内容均来自于互联网或第三方用户上传分享，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系youleyoucom@outlook.com。

上一篇：总结 Java 并发编程底层逻辑：从缓存一致性协议到 JVM 内存屏障的全栈性能调优路径下一篇：ThinkPHP如何做数据库主从切换演练_ThinkPHP故障转移测试详解【详解】