5.3 OutOfMemoryError：内存弹尽粮绝时

5.3 OutOfMemoryError：内存弹尽粮绝时

本节摘要：Maven 构建的内存溢出分三类归属——构建进程自身、测试 fork 进程、被测应用进程，各自有不同的参数入口。堆溢出、元空间溢出、直接内存溢出的症状与处方各异，forkCount 与 argLine 的配置是处置核心。本节给出归属判定流程与三类 OOM 的实战配置。

先分清：谁在溢出

CI 在满负荷时段开始随机报 OOM。第一个动作不是加内存，是判定溢出归属——Maven 的世界里同时存在三类 JVM：

JVM 一：构建进程自身（跑 Maven 核心与插件）
  参数入口：环境变量 MAVEN_OPTS 或 mvn 脚本的 JVM 参数
  典型溢出：超大项目的依赖解析 树过深或模块过多

JVM 二：测试 fork 进程（surefire 起来跑测试的独立进程）
  参数入口：surefire 的 argLine 配置
  典型溢出：测试数据加载过猛 内存泄漏累积

JVM 三：被测应用进程（集成测试启动的真实服务）
  参数入口：测试框架的应用启动配置
  典型溢出：应用自身内存配置不足
​

归属判定的依据是报错堆栈的"出身"：堆栈顶是 Maven 内部类，归属 JVM 一；堆栈在 surefire 的 fork 通信层，归属 JVM 二；堆栈在应用代码与业务线程，归属 JVM 三。CI 那次故障的堆栈顶部是 fork 通信类——JVM 二，测试进程溢出。

三类溢出的症状与处方

堆溢出（Java heap space）。 最常见，症状直白。处方先分清是"配置不够"还是"泄漏"：给 JVM 二 加堆的配置写法有个高频坑——直接改 MAVEN_OPTS 没用，因为那是 JVM 一 的参数：

<!-- 正确入口：surefire 的 argLine 归 fork 进程 -->
<plugin>
  <groupId>org.apache.maven.plugins</groupId>
  <artifactId>maven-surefire-plugin</artifactId>
  <configuration>
    <!-- fork 测试进程的堆上限调到 2G -->
    <argLine>-Xmx2g -Xms512m</argLine>
    <!-- forkCount 控制并发 fork 数 每个都要吃一份内存 -->
    <forkCount>2</forkCount>
    <reuseForks>true</reuseForks>
    <!-- 复用 fork：测试类共享进程 避免反复冷启动 -->
  </configuration>
</plugin>
​

配完内存翻倍还溢出，方向就要转向泄漏排查：用堆转储（JVM 参数加堆转储路径）拿快照，分析占大头对象。risk-engine 那次 CI 故障的最终结论是一个测试工具类没释放本地缓存，修一处代码胜过加十 G 内存。

三步判定的实操命令链也值得抄走：

# 第一步：复现时开着详细 GC 日志 观察是缓涨还是陡涨
# 缓涨到顶：泄漏 陡涨到顶：单次大对象分配

# 第二步：堆转储配置加进 argLine 复现一次
<argLine>-Xmx2g -XX:+HeapDumpOnOutOfMemoryError</argLine>
# 溢出瞬间生成转储文件

# 第三步：转储文件用分析工具打开 按对象保留大小排序
# 头部就是泄漏主体或大对象来源
​

元空间溢出（Metaspace）。 症状是加载类过多撑爆类元数据区。典型诱因：大量动态代理、脚本引擎、或 fork 复用策略下跑了几千个测试类。处方双管：上调上限（argLine 加 -XX:MaxMetaspaceSize=512m）与降低类加载 churn（拆分过大的测试套件、关闭不必要的动态代理）。

直接内存溢出（Direct buffer）。 堆栈出现 NIO 相关字样。直接内存不吃堆，吃的是堆外配额，处方在 -XX:MaxDirectMemorySize，同时排查 ByteBuffer 使用方（有些客户端库的池化配置会放大直接内存占用）。

fork 策略：内存与速度的平衡木

forkCount 与 reuseForks 两个参数的组合决定测试进程的"编制"，也是内存事故的常发配置区：

⚠️ 常见坑一：为提速把 forkCount 拉高（比如 4C），CI 节点的总内存却是按单 fork 预算的。并发 fork 同时满载，OOM 从偶发变成常发。调 forkCount 的同时必须重算内存预算：单 fork 峰值乘以 forkCount，留出构建进程自身的份额。

⚠️ 常见坑二：argLine 被后续配置覆盖。 JaCoCo 等覆盖率插件通过 argLine 注入代理，若 surefire 的 argLine 硬写了内存参数，可能把代理参数顶掉，覆盖率静默归零。惯例做法是 argLine 里引用 @{argLine} 占位符，让各插件的注入可以叠加。

💡 关键直觉：内存问题的第一处方永远是"判定归属"，第二处方才是"调整参数"。盲目加内存最常见的结局是：把泄漏掩护过去，让它在三个月后以更大当量的形式回来。

战报小结

• 三类 JVM 三种入口：构建进程走 MAVEN_OPTS、测试 fork 走 argLine、被测应用走框架配置，归属判定看堆栈出身；
• 堆溢出先辨配置与泄漏：加内存只是处方一，堆转储分析才是终审；
• 元空间看类加载：上限调整与降低类加载 churn 双管齐下；
• 直接内存吃堆外配额：MaxDirectMemorySize 与使用方排查并重；
• fork 是内存乘数：forkCount 上调必须重算总预算，argLine 用占位符避免互相覆盖。

内存战场清了，下一节处理另一类流水线高发故障：插件版本兼容——升级 JDK 后插件集体罢工的完整处置。