1c1g 容器莫名 OOM Killed？排查 Metaspace 持续增长与脚本引擎的坑

最近在一个基于动态规则引擎的微服务遇到了一个典型的内存泄漏问题。容器规格较小（1c1g），运行一段时间后会被 Kubernetes 以 OOMKilled 状态强制重启。最终定位到是脚本引擎在底层产生了大量无法回收的 ClassLoader，导致 Metaspace 只增不减。本文记录了排查思路及不同引擎的底层差异对比。

一、问题现象：Heap 正常，Metaspace 持续上涨

业务容器配置为 1 Core / 1GB 内存，JVM 参数中 Heap 设置了 512MB，Metaspace 未设上限（默认无上限）。

监控数据显示：

Heap 内存水位正常：日常使用率在 40% 左右，Minor GC 正常清理短生命周期对象。
Metaspace 持续增长 ：从启动时的几十兆，以每天 20~30MB 的速度线性上涨，且从未出现过回落。
Full GC 极少发生：由于 Heap 空间充足，老年代对象积累缓慢，JVM 很少触发 Full GC。
最终结果：Metaspace 不断膨胀，挤占了越来越多的容器物理内存，当总内存使用逼近 1GB 时，触发 Linux 内核的 OOM Killer，容器被直接杀掉重启。

二、为什么 Full GC 没能回收 Metaspace？

很多同学有一个误区：认为只要触发 Full GC，JVM 就会顺带把 Metaspace 里的废弃类清理掉。实际上，Metaspace 的回收条件非常苛刻。

一个类及其元数据要被卸载，必须同时满足三个条件：

该类所有的实例都已被 GC 回收。
加载该类的 ClassLoader 实例已经被 GC 回收。
对应的 java.lang.Class 对象没有任何引用。

核心在于第 2 点：ClassLoader 必须先死，它加载的类才能死。

在我们的场景中，由于 Heap 足够大，短生命周期业务对象在 Minor GC 就被清理了，老年代增长慢，JVM 缺乏触发 Full GC 的压力。即使偶尔触发了一次 Full GC，由于某些动态生成的 ClassLoader 被隐蔽的 GC Root（如 ThreadLocal、未关闭的 Context 对象）间接引用，依然无法满足回收条件，导致 Metaspace 只增不减。

对于 1c1g 的小规格容器，这种缓慢的泄漏是致命的，不到几天就会触及物理内存天花板。

三、步步为营：从 NMT 到 Arthas 的精准排查

既然怀疑是类加载导致的泄漏，我们并没有急于去拉几 GB 的 Heap Dump（在 1c1g 容器上拉 Dump 极易导致应用卡死或二次 OOM），而是采用了一套轻量级的组合拳来精准定位。

1. 宏观定性：NMT 确认内存增长区域

首先，我们在 JVM 启动参数中开启了 Native Memory Tracking (-XX:NativeMemoryTracking=summary)。应用启动稳定后，执行命令建立基准：

bash 复制代码

jcmd <pid> VM.native_memory baseline

运行一段时间后，观察内存差异变化：

bash 复制代码

jcmd <pid> VM.native_memory summary.diff

输出结果中，其他区域（如 Heap、Thread）基本只有极小的波动，唯独 Class 区域 出现了显著的正向增长（带有 + 标志）：

text 复制代码

-                    Class (reserved=1283311KB +13614KB, committed=279919KB +17070KB)
                            (classes #30595 +1610)
                              (malloc=19695KB +1326KB #133906 +6398) 
                              (mmap: reserved=1263616KB +12288KB, committed=260224KB +15744KB)

这段 NMT 报告直接定性了问题本质，我们需要重点解读三个关键指标：

(classes #30595 +1610) ：这是最核心的铁证！应用启动时加载了 30595 个类，而在观察窗口内，新增了 1610 个类。对于业务平稳运行的服务，类数量应该是恒定的，这种持续的增加绝对异常。
committed=279919KB +17070KB：意味着 JVM 向操作系统真实申请了约 16.6MB 的物理内存来存放这些新增的类元数据，且这部分内存属于 Metaspace，不被常规的 Heap GC 管控。
malloc=... +1326KB #... +6398 ：malloc 次数增加了 6398 次。在 JVM 底层，每一个类加载不仅需要 mmap 分配 Metaspace 空间存放字节码结构，还需要 malloc 分配 C++ 层的 InstanceKlass 等元数据对象。新增的 6398 次 malloc 分配，与新增的 1610 个类完全吻合。

NMT 结论：问题根因是类加载器在不断地、高频地创建新的类，且无法被卸载回收，导致 Metaspace 只增不减。

2. 微观定位：JFR 锁定罪魁 ClassLoader

知道了是类不断增加，接下来要找出是谁在疯狂加载类。我们使用了 JFR (Java Flight Recorder)，它对性能影响极小，非常适合生产环境动态开启。

bash 复制代码

# 开启 JFR 录制，记录 ClassLoad 事件，持续 60 秒
jcmd <pid> JFR.start name=classload settings=profile duration=60s filename=/tmp/classload.jfr

将录制的 .jfr 文件下载到本地，使用 JDK Mission Control (JMC) 分析。在事件浏览器中筛选 Class Load 和 Class Define 事件，我们看到了极其密集的加载记录，且加载这些动态类的 ClassLoader，全都是 org.mozilla.javascript.DefiningClassLoader。

3. 抓取现行：Arthas 找出业务调用源

罪魁祸首找到了，但它是底层组件，我们必须查出是哪行业务代码在触发这些创建。这时候 Arthas 登场了。

使用 Arthas 的 stack 命令，直接跟踪 DefiningClassLoader 的构造函数，打印出完整的调用栈：

bash 复制代码

stack org.mozilla.javascript.DefiningClassLoader <init>

很快，控制台吐出了调用链，真相大白：

java 复制代码

[arthas@12345] stack org.mozilla.javascript.DefiningClassLoader <init>
... 省略部分内部栈 ...
at org.mozilla.javascript.Context.compileString(Context.java)
at com.xxx.business.RuleEngineService.executeDynamicRule(RuleEngineService.java:45)
...

顺着调用栈，我们直接定位到了业务代码 RuleEngineService.java 的第 45 行：

java 复制代码

Context cx = Context.enter();
try {
    // 🚨 致命问题在此：开启了编译优化，将 JS 编译为 Java 字节码执行
    cx.setOptimizationLevel(9); 
    // 每次请求都根据不同规则动态编译
    Script script = cx.compileString(dynamicRuleScript, "rule_" + ruleId, 1, null);
    script.exec(cx, scope);
} finally {
    Context.exit();
}

四、根因剖析：Rhino 编译模式的底层灾难

问题出在 OptimizationLevel > -1 时的底层机制：

当 Rhino 编译 JS 代码时，会将 JS 转换为 Java 字节码。为了支持单个脚本的独立卸载，Rhino 的设计策略是：为每一个编译生成的脚本类，单独创建一个 DefiningClassLoader。

在我们的动态规则场景下，每天几万条不同的规则输入，意味着每天几万个 DefiningClassLoader 和对应的 Class 被注入 Metaspace。加上复杂的 Web 容器引用链，这些 Loader 极难被 GC，最终变成了 Metaspace 里的僵尸。

五、引擎对比：Rhino vs Nashorn vs GraalJS

动态脚本引擎的 ClassLoader 策略直接决定了 Metaspace 的健康状况。我们做个横向对比：

1. Rhino (编译模式, Opt > -1)

执行机制：JS 代码 -> 生成 Java 字节码 -> 实例化 Class。
ClassLoader 策略 ：1 个脚本 = 1 个 DefiningClassLoader。
影响：极度碎片化，极易引发 Metaspace OOM。在小规格容器上应绝对禁用。

2. Rhino (解释模式, Opt = -1)

执行机制：JS 代码 -> 内部 AST 遍历解释执行 -> 不生成字节码。
ClassLoader 策略 ：0 个动态 ClassLoader 。脚本统一映射为 Jar 包内固定的 InterpretedScript 类，由 AppClassLoader 加载。
影响：Metaspace 绝对安全，零泄漏风险。代价是纯解释执行速度较慢，且不支持现代 ES6+ 语法。

3. Nashorn (JDK 8 内置)

执行机制：JS 代码 -> 生成 Java 字节码 -> 实例化 Class。
ClassLoader 策略 ：所有脚本共享 1 个 DynamicClassLoader。
影响：避免了碎片化，但也更难卸载。只要还有 1 个脚本类在用，整个庞大的 Loader 及其装载的所有 Class 都无法被 GC。长期运行依然存在 Metaspace 增长风险。且 JDK 15 后已被官方废弃。

4. GraalJS (现代终极解)

执行机制 ：JS 代码 -> Truffle AST -> JVM 直接解释并 JIT 优化 AST 本身 -> 不生成任何 Java 字节码。
ClassLoader 策略 ：0 个动态 ClassLoader。代码逻辑用普通 Java 对象（AST 节点）表达，无类动态生成。
影响：对象死亡直接在普通 Heap 中被 GC，从机制上彻底规避了 Metaspace 泄漏。性能极佳，完全支持现代 ES6+ 语法。

简单测试验证：循环编译 5 个不同的脚本，观察底层对象的 ClassLoader HashCode。

Rhino(编译)：HashCode 每次都变 (不断新建 Loader)

Nashorn：HashCode 始终一致 (共享同一个 Loader)

GraalJS：HashCode 始终一致 (复用 AppClassLoader，无动态类生成)

六、务实选型建议（针对不同 JDK 版本）

针对这次 1c1g 容器的 OOM 问题，以及不同的技术栈现状，给出以下务实的解决路径：

🥇 对于 JDK 8 / JDK 11 项目：首选 Rhino 解释模式

在老旧的 JDK 版本上，不建议强行引入 GraalJS。GraalJS 对 JDK 8/11 的最后支持版本是 22.3.3，不仅引入了 20多MB 的庞大第三方依赖，而且该版本已经停维，存在未知风险和技术债。

最稳妥、成本最低的止血方案是：留在 Rhino，但立刻切到解释模式。

java 复制代码

Context cx = Context.enter();
try {
    // 关闭字节码生成，杜绝 DefiningClassLoader 创建
    cx.setOptimizationLevel(-1); 
    // ... 执行脚本逻辑
} finally {
    Context.exit();
}

优势：只需改动一行代码，引入的 Rhino Jar 仅 1MB，Metaspace 泄漏瞬间归零。劣势：执行速度变慢，无法使用 ES6 语法。但对于大多数后端的轻量级规则引擎（如简单的条件判断、属性映射），解释模式的性能消耗通常在可接受范围内。

🥈 对于 JDK 17 / JDK 21+ 项目：拥抱 GraalJS

如果你已经享受到了现代 JDK 的红利，那么 GraalJS 是唯一正道。它彻底抛弃了老旧的字节码生成机制，从架构根源上消灭了类泄漏，同时带来了顶级的执行性能和完整的现代语法支持。

Maven 依赖配置（适用于 JDK 17+）：

xml 复制代码

<dependency>
    <groupId>org.graalvm.polyglot</groupId>
    <artifactId>polyglot</artifactId>
    <version>23.1.1</version> <!-- JDK 17+ 使用最新版 -->
</dependency>
<dependency>
    <groupId>org.graalvm.js</groupId>
    <artifactId>js</artifactId>
    <version>23.1.1</version>
</dependency>

🔒 运维兜底防线：限制 Metaspace 上限

无论采用哪种方案，对于 1c1g 等小规格容器，务必加上 Metaspace 上限限制，防止无限膨胀吃光物理内存被内核 Kill。即使真有泄漏，也能让 JVM 尽早抛出 OOM 异常而重启，而不是被内核悄无声息地抹杀，导致排查无迹可寻。

bash 复制代码

-XX:MaxMetaspaceSize=256m  # 1c1g容器建议限制在256m以内，留足空间给Heap和Native

💡 附加性能优化：缓存编译结果

无论使用 Rhino 解释模式还是 GraalJS，动态脚本的"编译/解析"动作本身都是消耗 CPU 的。对于高频执行且内容固定的规则，务必在应用启动时或首次执行时解析好，并将 Script / Value 对象缓存起来复用，避免每次请求都重新解析字符串。

结语

在 1c1g 等小规格容器中，任何微小的内存泄漏都会被迅速放大。排查此类问题时，NMT 定性区域、JFR 定性组件、Arthas 找出调用栈，是一套低影响、高效率的实战组合拳。

动态生成 Java 字节码并依赖 ClassLoader 卸载来清理 Metaspace，在现代 JVM（尤其是 G1/ZGC 倾向减少 Full GC 的趋势下）是一个极其脆弱的设计。遇到 Metaspace 只增不减，先查 ClassLoader 来源。选型修复时，务必要结合自身的 JDK 版本：老项目用 Rhino 解释模式稳妥止血，新项目用 GraalJS 彻底治本。 不要为了追求纸面上的引擎性能，在老旧 JDK 上引入沉重的停维依赖，那只会让技术债越滚越大。

1c1g 容器莫名 OOM Killed？排查 Metaspace 持续增长与脚本引擎的坑

一、 问题现象：Heap 正常，Metaspace 持续上涨

二、 为什么 Full GC 没能回收 Metaspace？

三、 步步为营：从 NMT 到 Arthas 的精准排查

1. 宏观定性：NMT 确认内存增长区域

2. 微观定位：JFR 锁定罪魁 ClassLoader

3. 抓取现行：Arthas 找出业务调用源

四、 根因剖析：Rhino 编译模式的底层灾难

五、 引擎对比：Rhino vs Nashorn vs GraalJS

1. Rhino (编译模式, Opt > -1)

2. Rhino (解释模式, Opt = -1)

3. Nashorn (JDK 8 内置)

4. GraalJS (现代终极解)

六、 务实选型建议（针对不同 JDK 版本）

🥇 对于 JDK 8 / JDK 11 项目：首选 Rhino 解释模式

🥈 对于 JDK 17 / JDK 21+ 项目：拥抱 GraalJS

🔒 运维兜底防线：限制 Metaspace 上限

💡 附加性能优化：缓存编译结果

结语

一、问题现象：Heap 正常，Metaspace 持续上涨

二、为什么 Full GC 没能回收 Metaspace？

三、步步为营：从 NMT 到 Arthas 的精准排查

四、根因剖析：Rhino 编译模式的底层灾难

五、引擎对比：Rhino vs Nashorn vs GraalJS

六、务实选型建议（针对不同 JDK 版本）