如果你经历过凌晨两点的告警电话，看到日志里出现java.lang.OutOfMemoryError: Metaspace，大概率会心头一紧。OOM 的种类很多，堆内存 OOM 大家见得比较多，Metaspace OOM 属于那种“平时不常见，一出现就很难缠”的类型。最近我复盘了一次真实的生产事故：服务在高峰期突然无法处理请求，系统可用内存持续下降，最后靠转储文件和类加载器统计定位到一个动态脚本执行导致的类加载器泄漏。这篇文章把完整的排查流程、参数调优思路和日常预防方法写下来，既给需要处理同类问题的人一个可以照做的参考，也能当作应对面试官追问 OOM 时的实战素材。
1. 先把基础打牢：Metaspace 是什么，为什么它会 OOM
1.1 Metaspace 在 JVM 内存模型里的位置
很多同学能把堆内存、栈内存背得很熟，但一提到 Metaspace 就含糊。简单说，Metaspace 是 JDK 8 及以后版本里方法区的实现，用来存放类的元数据信息，比如类的结构、方法字节码、字段信息、注解、常量池、方法签名等。你可以把它理解成一个仓库，里面放的是所有类的“设计图纸”。JVM 运行时每加载一个类，都要往这个仓库里放入一张图纸。
类在什么时候被加载？启动时加载基础类库，运行中反射调用、动态代理生成新类、JSP 首次编译、脚本引擎执行脚本，都会触发类加载。图纸放进仓库后，大部分情况不会频繁变化，但如果某个逻辑不断制造全新的类，仓库就会持续膨胀。Metaspace 和堆内存最大的区别之一就在这里：堆内存装的是对象实例，对象没人引用后可以被 GC 回收；而 Metaspace 装的是一类类的元数据，只有对应类加载器不再被引用时，这些元数据才可能被回收。所以，Metaspace OOM 的根源，往往不是“容量不够”，而是“类加载器回收不掉”。
1.2 Metaspace 和 PermGen 的区别，为什么 JDK 8 要换掉永久代
在 JDK 7 及以前，方法区的实现在堆内的永久代（PermGen），它的大小是启动时就确定的，用-XX:PermSize和-XX:MaxPermSize控制。永久代有几个问题：
- 大小固定，很难预估一个应用到底需要多少；
- 可回收条件苛刻，在频繁生成类时容易 OOM；
- 和堆内存挤在一起，调参时要同时考虑堆和永久代，稍不注意就冲突。
JDK 8 把永久代移除，改成 Metaspace —— 它使用本地内存，默认情况下只受操作系统可用内存限制。这意味着，如果你不显式设置上限，Metaspace 理论上可以一直涨到把系统内存吃光。这也是生产环境里 Metaspace OOM 特别危险的原因之一：它不是立刻报错，而是先悄悄吃掉机器内存，直到触发操作系统层面的资源告警，服务才开始全面异常。
1.3 Metaspace OOM 最常见的四类触发场景
根据我见过的案例，Metaspace OOM 基本逃不出下面四类场景：
第一类是动态生成类没有控制好数量。比如 CGLIB 动态代理、Java 反射生成代理类、Groovy 或 JavaScript 引擎执行脚本，每次执行都生成新的类，类加载器又不复用，最终把 Metaspace 撑爆。
第二类是自定义类加载器泄漏。框架、应用服务器、热部署插件会创建很多类加载器，如果这些类加载器被长生命周期的对象引用，就无法被 GC，类也就永远卸载不掉。
第三类是热部署/不停机发布。每次发布都创建新的类加载器来加载新版本，但老的类加载器没有被清理，累计多次后 Metaspace 就被消耗光了。
第四类是框架设计缺陷或使用姿势不对。比如日志框架的类缓存、规则引擎的脚本缓存、模板引擎频繁编译模板，都可能让类的数量持续上涨。
面试官问“Metaspace OOM 常见场景有哪些”，你把这四类答出来，再结合一次定位过程说明，这一题基本稳了。
2. 一次真实生产 Metaspace OOM 的完整排查过程
2.1 事故现场：从告警到服务无响应
那次事故发生在下午业务高峰期。监控系统先报出“容器内存使用率超过 85%”，紧接着网关开始出现大量超时，随后应用日志里出现了一行很扎眼的异常：
java.lang.OutOfMemoryError: Metaspace更麻烦的是，服务虽然还活着，但已经不具备处理业务请求的能力。第一反应当然是重启，但这里有个关键原则：如果没有保留现场，重启后你就永远不知道根因是什么。我们的做法是先摘流量，保留进程，让运维同事确认是否可以用临时扩容顶上，同时我这边立刻开始收集证据。
你需要具备一个意识：OOM 期间，进程状态非常脆弱。能不下去 dump 就不要轻易执行重操作，优先采集轻量级数据：GC 日志、jstat 输出、进程线程状态。等确认这些信息到手，再做堆转储或重启。
2.2 第一轮：用监控和 jstat 锁定非堆内存异常
由于服务还有监控系统，我先打开了 JVM 监控面板。Metaspace 的使用曲线触目惊心：在事故前一个月基本稳定在 300MB 左右，但最近三天开始阶梯式上涨，从 400MB 一路涨到 1.6GB，并且完全没有回落的迹象。
为了进一步确认，我在服务器上执行了：
jstat -gcutil <pid> 1000输出里的关键指标是MU（Metaspace Used）和MCC（Compressed Class Space Used）。正常情况下，这两个值会平稳，Full GC 之后如果有类加载器可回收，还会出现小幅下降。但我们看到的是：每次 Full GC 之后，Metaspace 占用纹丝不动，甚至还在涨。这就基本排除了“业务对象创建过多导致堆 OOM”的可能，把问题锁定到了类元数据层面。
这里有个技巧：不要只看当前值，要看变化趋势。很多 OOM 用jstat看一眼只能得到一刹那的快照，无法判断是正常波动还是泄漏。要把采样时间拉长，比如每 2 秒采一次，持续 5 分钟，然后观察曲线是否单调上涨。
2.3 第二轮：类加载器统计，找到最可疑的对象
既然怀疑是类加载器问题，下一步就看类加载器数量和每个加载器加载的类数量。JVM 自带的jcmd命令很好用：
jcmd <pid> GC.class_loader_stats输出里能看到每个类加载器的名称、加载类数量、保持的已卸载类数量等。同时执行：
jcmd <pid> GC.class_histogram看到的结果让我立刻警觉：java.lang.ClassLoader相关的对象数量异常多，且有大量同一前缀、数字后缀的类。比如业务里某个规则引擎的类，出现了几百个不同的版本，类似：
com.example.rulerule.engine.ScriptRule_3872837 com.example.rulerule.engine.ScriptRule_3872838 com.example.rulerule.engine.ScriptRule_3872839这样的命名格式说明两个信息：第一，这些类是运行时动态生成的；第二，生成时大概率带了时间戳、随机数或自增 ID，导致每次生成的类名都不一样。类名不同，JVM 就会认为这是全新的类，必须加载全新的元数据。哪怕业务上这些类的逻辑完全一样，Metaspace 也不会去复用。
这一步已经能非常明确地指向动态脚本执行。我们的服务里有一段用 Groovy 脚本实现的规则逻辑，每次请求过来，如果脚本被判断为“有变化”，就会创建一个新的GroovyClassLoader来加载新的脚本类，而旧的类加载器虽然不再使用，却被一个全局的 Map 缓存引用，导致它永远无法被回收。类加载器不回收，它加载过的所有类元数据就都不会被 JVM 卸载。
2.4 第三轮：堆转储与 MAT 分析，锁定根因
动态类只是表象，真正的泄漏点还要看是谁持有这些类加载器。我用jmap生成了堆转储文件：
jmap -dump:live,format=b,file=app_metaspace_oom.hprof <pid>这里必须插一句：生产环境执行带live参数的 dump 会触发一次 Full GC，随后再转储，期间 JVM 会有较长时间的停顿。小服务还好，大流量服务的停顿可能造成雪崩。所以这步操作要在已经决定“保留现场、临时摘流量”的前提下进行，不要在最繁忙的时候贸然执行。如果不方便停机分析，也可以退而求其次，借助Arthas在线查看类加载器相关的引用链，但堆转储仍然是定位类加载器泄漏最可靠的方式。
拿到 dump 文件后，我导入 MAT（Eclipse Memory Analyzer）进行分析。MAT 的直方图里能看到各个类的实例数量，但定位类加载器泄漏要看的是引用关系。我用的方法是：
- 点击 Histogram，搜索
GroovyClassLoader，会看到还有大量实例存活； - 右键对象，选择 Merge Shortest Paths to GC Roots，排除弱引用和软引用；
- 在引用链里看到了一条清晰的路径：某个静态 Map 缓存了历史脚本的
ClassValue，而 ClassValue 内部持有GroovyClassLoader的引用。
到这里根因 100% 确认：一个静态缓存 + 每次动态创建新的类加载器，组合成了双保险泄漏，Metaspace 不涨才怪。业务上看起来是“规则自动更新”，实际上每次规则变更都会把旧的类加载器地址写进静态缓存，再也没有机会释放。
2.5 为什么这次 OOM 没有被 GC 救回来
很多面试官会用一个问题把排查者问倒：“既然 Metaspace 是本地内存，GC 能不能回收它？”答案是：能回收，但有前提。
Metaspace 的回收依赖类加载器变为不可达状态。只要类加载器还被引用，它加载的所有类就都属于根可达状态，GC 判断不了这些元数据是垃圾。我们这次事故恰好踩中两个条件：静态缓存导致类加载器长期存活，动态类名导致每次生成的类都是新类，所以任何 GC 策略都无法释放已经占用的 Metaspace。给 JVM 多高的MaxMetaspaceSize都只是延迟爆炸时间，真正的解法是切断引用，让类加载器可以被回收。
3. 解决与预防：从 JVM 参数到代码重构，再到上线验证
3.1 JVM 参数怎么调才不挖坑
先纠正一个误区：遇到 Metaspace OOM 就调大MaxMetaspaceSize，这是典型的“治标不治本”。如果原因不是类数量真的多，而是类加载器泄漏，调多大都没用，内存迟早还是会被吃光。正确的做法是，先确保你的 JVM 参数能提供足够的监控信息，再根据实际情况合理设置阈值。
生产环境至少要把这几个参数加上：
-XX:+UseConcMarkSweepGC # 如果用的老版本 JDK 8，按实际 GC 方案来 -XX:MetaspaceSize=256m -XX:MaxMetaspaceSize=512m -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/data/logs/jvm/app_oom.hprof -XX:+ExitOnOutOfMemoryError这里说几个容易被忽略的点：
MetaspaceSize是触发 Metaspace 区域 GC 的阈值，不是初始分配值。它的作用是让 Metaspace 用量达到这个值后触发一次 Full GC 来尝试回收类的元数据。设得过低，比如默认的 20.8MB，会导致服务刚启动没多久就频繁 Full GC，白白消耗性能；设得过高，比如 1GB，虽然不频繁 GC，但会让内存浪费在闲置的元数据空间上。比较稳妥的做法是：观察上线初期平稳运行的 Metaspace 用量，然后把这个值设到用量的 2 倍左右，再给MaxMetaspaceSize留出同样比例的余量。
MaxMetaspaceSize是 Metaspace 能申请本地内存的上限。如果完全不设置，JVM 会持续向操作系统申请内存，直到机器内存耗尽。在容器化部署下，这点尤其危险，因为容器的内存上限是固定的，JVM 看到可用内存还有剩余，会继续申请，最后被 Kubernetes 或 Docker 的 OOM Killer 杀掉。这也是为什么我建议生产环境一定要显式设置上限，同时给堆内存之外的元数据区域留出空间。
还有-XX:CompressedClassSpaceSize，这个参数控制压缩类空间的大小，默认是 1GB。如果你在 64 位 JDK 上启用了类指针压缩，类加载时会在一个连续的内存区域分配 Klass 元数据。如果系统里类特别多，这个区域也可能成为新的瓶颈。排查时如果发现 Metaspace 总量没到上限，但报错信息是OutOfMemoryError: Compressed class space，就要考虑调整这个参数。
3.2 代码层面切断类加载器泄漏
JVM 参数只是安全网，真正要解决的是代码里的泄漏点。那次事故的修复方案看起来很简单：不缓存历史脚本的 ClassValue，改为复用同一个GroovyClassLoader，并通过GroovyCompiledScript缓存编译结果。但落地时还有一些细节要注意。
先说复用类加载器。Groovy 脚本执行慢的核心在于每次编译脚本都要解析、生成字节码、加载类。正常写法应该是：
- 项目启动时创建一个全局唯一的
GroovyClassLoader； - 每个脚本执行前先检查是否已编译，编译结果放进 ConcurrentHashMap；
- 脚本内容改变时才重新编译，并替换 Map 里的旧引用；
- 旧编译结果的类加载器如果本身就是全局唯一的，就不存在大量类加载器泄漏的问题。
市面上还有很多类似的动态执行场景，我用表格把常见情况和修复思路整理一下，方便直接对照使用：
| 动态执行方式 | 泄漏风险点 | 核心修复思路 |
|---|---|---|
| Groovy/JavaScript 引擎执行脚本 | 每次 new 脚本引擎或 ClassLoader | 复用引擎或 ClassLoader，缓存编译结果 |
| CGLIB/ByteBuddy 生成代理类 | 代理类生成过多且无缓存 | 启用缓存，避免重复创建相同代理类 |
| Spring Boot devtools 热部署 | 多次重启后类加载器累积 | 限制重启次数，发布时使用全量重启 |
| JSP/模板引擎 | JSP 修改后重编译产生新类 | 预编译模板，减少运行时编译 |
| 规则引擎动态加载 jar | ClassLoader 被静态 Map 持有 | 使用弱引用缓存，明确释放时机 |
这段修复过程给我最深的体会是：动态执行是 Metaspace OOM 的头号温床，凡是会创建新类的代码，都要回答一个问题——“这个类会被创建多少次？它是不是可被回收的？”如果答不上来，就说明这里有风险。
3.3 上线后的验证和长期预防
修复代码不是改完就结束，必须验证。我们当时的验证分三步：
第一步，在测试环境用压测工具模拟高峰期请求，同时持续采集 Metaspace 使用率。要求连续运行 48 小时，Metaspace 曲线保持平稳，Full GC 次数没有异常增长。
第二步，在生产环境灰度发布，把新版本部署到一台机器上，给它几天的观察窗口。我特意在监控面板上同时对比旧版本机器和新版本机器的 Metaspace 曲线，能非常直观地看到修复效果。旧的版本曲线一直往上爬，新的版本曲线像一条直线。
第三步，建立长期预防机制。代码评审时加了一条规则：动态生成类、动态脚本、自定义类加载器，必须写明生命周期和回收方式。监控告警里也加了 Metaspace 使用率的环比增长检测，一旦出现连续多个周期上涨，立刻触发人工确认。
顺便说一句，如果你负责的平台有持续发布需求，并且使用 Spring Boot devtools 做本地热部署，要特别注意它在生产环境是默认关闭的，但开发环境里反复热加载会积压大量类加载器。这种一般不会直接让生产崩溃，但会拖慢 IDE 响应，还会占用大量堆外内存，建议开发环境也设置合适的MaxMetaspaceSize并定期重启。
4. 开发测试阶段的 OOM 防护：IDEA 配置与日常检查
4.1 IDEA 的 JVM 内存怎么设置
日常开发最常见的 OOM 反而不是生产环境，而是本地 IDEA 或本地跑服务时频繁报OutOfMemoryError。很多人只会在 IDEA 右下角看到“内存不足”的提示，然后重启大法了事。实际上，IDEA 本身就是一个 JVM 应用，它既要加载工程依赖，又要跑编译、索引、插件，堆内存和非堆内存的消耗都很可观。
IDEA 的 JVM 内存配置入口在Help -> Edit Custom VM Options，打开后是idea.vmoptions文件。我常用的配置是：
-Xms1024m -Xmx2048m -XX:ReservedCodeCacheSize=512m -XX:+UseCompressedOops当然，具体数值要看机器配置。如果你是 8GB 内存的机器，给 IDEA 分配 2GB 堆已经很有压力，建议把多余的插件禁用，不要盲目调大。对于 16GB 及以上的机器，可以适当给到 2GB 到 4GB。
这里有个很多人不知道的小技巧：IDEA 里跑 Spring Boot 项目时，实际进程是你配置的 Run Configuration，而不是 IDEA 本身。你要在Run/Debug Configurations里找到对应的 Application，然后在VM options里设置：
-Xms512m -Xmx1024m -XX:MetaspaceSize=256m -XX:MaxMetaspaceSize=512m这个配置解决的问题是：本地服务如果使用了大量动态代理或模板编译，Metaspace 会涨得很快；如果不加MaxMetaspaceSize，它可能吃掉你大半内存，导致电脑卡顿。加上参数后，即使发生 Metaspace 增长异常，也不会长到把整个电脑拖垮。
4.2 本地跑服务时的 OOM 防护清单
开发测试阶段防止 OOM，不要等到报错了才处理。我给自己定了一个简单清单：
- 本地启动服务前，先看一眼机器剩余内存。如果内存占用超过 80%，优先关掉不需要的应用再启动服务。
- Run Configuration 里明确设置堆内存和非堆内存上限，不要用默认的无限增长模式。
- 写单元测试或压测脚本时，确保生成的动态类数量可控。有些测试框架会每次执行都生成代理类，跑多了本地 IDE 也会 OOM。
- 如果本地要长时间挂着服务调试，建议在内存监控面板里加一个 Metaspace 的图表，或者直接安装一个 JVM 监控插件，随时观察曲线，避免等到卡死才反应过来。
- 遇到疑似内存问题，先看 IDEA 左下角的内存指示器，再决定是重启服务还是重启 IDE。很多时候只是某个插件产生的大量类元数据没有释放。
开发环境出 OOM 和生产环境出 OOM，解决问题的思路完全一致，只是规模更小、影响更小而已。但正因为影响小，很多人忽略了排查机会，错失了积累经验的时机。我建议每个开发者都养成一个习惯：本地一旦出现 OOM，不要急着点 restart，先看日志、用 jcmd 或 jstat 查一下状态，花十分钟做一次快速定位。这个练习成本极低，到了生产事故现场才不至于手忙脚乱。
5. 生产 OOM 的排查工具箱与高频问题速查
5.1 常用排查命令与环境准备
OOM 排查拼的是“现场保护”和“工具熟练度”。你要在故障发生的第一时间做出判断：先跑哪些命令，后跑哪些命令，哪些操作绝对不能做。我整理了一份自己常用的命令清单，每一行都是实战里验证过的：
| 目标 | 命令 | 说明 |
|---|---|---|
| 查看 Java 进程列表 | jps -l | 先确认进程 PID |
| 查看 GC 情况 | jstat -gcutil <pid> 1000 | 每秒采样一次，观察堆和非堆趋势 |
| 查看类加载器统计 | jcmd <pid> GC.class_loader_stats | 确认类加载器数量和已卸载类情况 |
| 查看类实例直方图 | jcmd <pid> GC.class_histogram | 发现异常数量的动态类 |
| 查看 JVM 参数 | jcmd <pid> VM.flags | 确认启动参数是否合理 |
| 转储堆文件 | jmap -dump:live,format=b,file=app.hprof <pid> | 有一定停顿风险，谨慎使用 |
| 在线排查工具 | arthas | 适合无法 dump 的场景，可查引用链 |
除了命令，日常就要把基础工作做好：一是开启 GC 日志，二是配置HeapDumpOnOutOfMemoryError。没有 GC 日志的 OOM 事故，排查难度会直接翻倍。这里多说一句，JDK 8 的 GC 日志参数是-Xloggc:/data/logs/gc.log -XX:+PrintGCDetails -XX:+PrintGCDateStamps，JDK 11 及以后则是-Xlog:gc*:file=/data/logs/gc.log这种新语法。生产环境应该根据 JDK 版本把 GC 日志提前配好，这是花最小成本换最大收益的配置。
5.2 生产现场最常见的四个坑
第一坑是上来就重启。服务挂了，很多人第一件事就是重启保命，这没错，但前提是已经保留了足够的现场信息。如果连 GC 日志和堆转储都没有，重启之后你面对的就是一个黑盒，只能靠猜。
第二坑是在流量高峰期直接 dump 大堆。jmap -dump:live会触发 Full GC，如果你的堆有 8GB、10GB，暂停时间可能长达十几秒。在网关超时阈值都很小的场景下，这个停顿会直接击垮下游。正确做法是先摘流量，或者离线分析副本，万不得已时才在线 dump。
第三坑是只调 JVM 参数，不管代码原因。Metaspace OOM 十有八九是类加载器泄漏，如果你只把MaxMetaspaceSize从 512M 调到 2G，下一次爆发只是时间问题，而且延迟爆发会有更大流量、更多类加载器，反而让现场更难分析。
第四坑是忽略容器内存边界。很多团队已经上了 Kubernetes，但 JVM 参数还停留在物理机时代的写法。比如容器限制内存 2G，JVM 堆设置 1.5G，却忘了 Metaspace、堆外缓存、线程栈都要占用内存。一旦三者叠加超过容器上限，进程会被系统杀掉，你以为的“OOM”其实是容器 OOM，这对排查方向会造成严重误导。
5.3 高频面试问题速查
面试官问 OOM，本质上是在考察你“是否真的处理过问题、会不会排查、对不同内存区域的理解是否透彻”。遇到 Metaspace OOM 相关的问题，可以参考下面这套回答思路：
问题一：Metaspace 和 PermGen 有什么区别？
回答时抓住三点：PermGen 位于堆内、大小固定；Metaspace 位于本地内存、默认可动态增长；Metaspace 区分了 Klass 部分和非 Klass 部分，参数也不同。如果你还能提到“Metaspace 的回收依赖类加载器不可达”，会显得理解更深一层。
问题二：Metaspace OOM 会出现在什么场景？
先答原理，再答案例。原理是类加载器无法被回收，案例可以说动态脚本、CGLIB 代理、热部署、规则引擎。把类名带时间戳这种细节说出来，面试官会有画面感。
问题三：MetaspaceSize和MaxMetaspaceSize的区别是什么？
MetaspaceSize是触发 GC 的阈值，MaxMetaspaceSize是上限。很多人会把这两者搞反，这是高频踩坑点。
问题四：遇到 OOM 你会怎么排查？
面试官其实不指望你把整个生产流程原封不动说出来，他期待的是“先看监控、再用 jstat、再查类加载器、再 dump 分析、最后修复验证”这个完整闭环。你如果能强调“不先重启、保留现场”，会非常有说服力。
问题五：Full GC 能回收 Metaspace 吗？
能，但前提是类加载器可以被回收。如果代码里某个静态 Map 一直持有类加载器引用，Full GC 再多次也没用。
把这几个问题答好，面试官大概率会认为你有真实排障经验，而不是只会背八股。重点是每一条都能配合实际场景展开，宁可从一次事故里讲细节，也不要泛泛而谈堆内存有多大、GC 算法有几种。
我在实际处理过几起 OOM 事故后，最大的感受是：这类问题真正让人紧张的并不是报错本身，而是你不知道它什么时候爆发、背后藏着什么架构缺陷。Metaspace OOM 尤其如此，它藏在 JVM 本地内存里，堆内存监控不看它一度让人很难察觉。回到那次生产事故，如果当时第一时间就把服务重启，我们永远不会发现规则引擎的类加载器泄漏，后续还会在某个深夜再次被同样的故障叫醒。如果你也想彻底掌握 OOM 排查，建议从设备环境开始，把 GC 日志打开，把常用命令练熟，把一个动态生成的类当作怀疑对象去追一次引用链，跑通两次之后，再复杂的 Metaspace OOM 也不会让你慌了。
