JVM Metaspace 排障：类加载太多也会把服务拖垮

原创于 2026-07-03 13:46:02 发布 · 59 阅读

本内容遵循CC 4.0 BY-SA版权协议

JVM Metaspace 排障：类加载太多也会把服务拖垮

JVM 排障时，大家经常关注堆内存和 GC，却忽略 Metaspace。Metaspace 存放类元数据，通常不像堆那样天天被盯着，但一旦类加载失控，服务会出现 Full GC、内存上涨、甚至 OutOfMemoryError: Metaspace。这类问题在动态代理、热加载、脚本引擎、插件系统和频繁创建 ClassLoader 的场景里很常见。

Metaspace 问题的关键，不是简单把 MaxMetaspaceSize 调大，而是找到类为什么越来越多。

一、先确认是不是 Metaspace 压力

flowchart TD
  A[Memory Rising] --> B{Heap Or Metaspace}
  B --> C[Heap Dump]
  B --> D[Class Loading Metrics]
  D --> E[ClassLoader Count]
  E --> F[Leak Candidate]

先看 JVM 指标：已加载类数量、卸载类数量、Metaspace used、committed、capacity。如果类数量只涨不降，就要警惕。

jcmd <pid> VM.native_memory summary
jcmd <pid> GC.class_stats
jstat -class <pid> 1000 5

不同 JDK 对命令支持略有差异，生产环境要提前验证工具链。

Native Memory Tracking (NMT) 是排查 Metaspace 问题的重要工具。它可以帮助你了解 JVM native 内存的分配情况，包括 Metaspace、CodeCache、Compiler、GC 等区域的使用。启用 NMT 会有一定性能开销，建议在测试环境默认开启，生产环境在排障时临时开启。通过对比不同时间点的 NMT 报告，可以发现哪类元数据在持续增长。

# 开启NMT
-XX:NativeMemoryTracking=detail

# 查看基线
jcmd <pid> VM.native_memory baseline

# 一段时间后对比
jcmd <pid> VM.native_memory summary.diff

二、常见根因是 ClassLoader 泄漏

类元数据通常跟 ClassLoader 生命周期绑定。如果 ClassLoader 被引用住，里面加载的类就无法卸载。比如线程上下文 ClassLoader、静态集合、缓存、定时任务引用，都可能导致泄漏。

common_causes
├── repeated dynamic proxy generation
├── Groovy or JS script engine reload
├── plugin classloader not closed
├── thread context classloader retained
└── static cache references generated classes

框架越灵活，越要关注类加载边界。动态能力不是免费的。

排查 ClassLoader 泄漏时，可以借助堆 dump 分析。用 MAT 或 JProfiler 查看 heap 中的 ClassLoader 实例，重点关注实例数量异常多、保留大小大、或预期应该被回收却还存活的 ClassLoader。进一步可以查看这些 ClassLoader 被谁引用，通常能在 GC Roots 路径中找到泄漏原因，比如 static Map、线程 ThreadLocal、或长生命周期的对象引用。

三、限制大小只是保护，不是修复

可以设置 -XX:MaxMetaspaceSize 防止进程无限吃内存，但这只是边界保护。

java \
  -XX:MaxMetaspaceSize=256m \
  -XX:+HeapDumpOnOutOfMemoryError \
  -XX:NativeMemoryTracking=summary \
  -jar app.jar

如果根因还在，限制只会让服务更早失败。它的价值是把问题暴露出来，并保护节点不被拖垮。

四、线上排查要保留证据

遇到 Metaspace 异常，不要只重启。至少保留类加载统计、NMT 输出、线程 dump、关键日志和版本信息。

evidence_pack
├── jstat class samples
├── jcmd VM.native_memory summary
├── thread dump
├── loaded class histogram
├── recent deployment version
└── plugin or script reload records

很多 Metaspace 问题和版本发布、配置热加载、插件升级有关。没有证据，重启后只能等下一次复现。

预防方面，建议在代码评审时关注动态类加载的使用。每次引入动态代理、脚本引擎、插件系统或自定义 ClassLoader 时，都要问清楚：这些类什么时候卸载？ClassLoader 什么时候回收？有没有可能泄漏？在测试环境可以编写长时间运行的稳定性测试，观察类加载指标是否平稳。预防的成本远低于线上排障。

在生产环境的监控侧，建议将 Metaspace 使用率纳入告警体系。我们设置了两个告警级别：Metaspace 使用率达到 80% 时发出 Warning 告警（提前 24 小时通知），达到 95% 时触发 Critical 告警（需要立即介入排查）。同时关注 ClassesLoaded 的持续增长趋势——如果 24 小时内加载了超过 10 万个新类且没有相应的卸载，这通常是 ClassLoader 泄漏的信号。配合 Micrometer 的 JvmMemoryMetrics，可以将这些指标无缝接入 Prometheus + Grafana，实现持续监控。建议在 Metaspace 告警的同时，自动采集一份 heap dump 和 class histogram 快照，避免事后排查时证据缺失。此外，JDK 21 引入的 -XX:+UnlockDiagnosticVMOptions -XX:+UnsyncloadClass 可以帮助诊断并发类加载的阻塞问题。同时建议在测试环境运行长期的稳定性测试，观察类加载指标曲线是否平稳。