GitLab CI内存溢出需分层应对：调大Node.js（NODE_OPTIONS）、Maven（MAVEN_OPTS）、Gradle（GRADLE_OPTS）进程内存上限；限制Runner并发数与Docker内存限制；规避git add大文件、禁用冗余步骤；通过free、docker stats等监控诊断。
GitLab CI 构建过程中出现内存溢出（如 JavaScript heap out of memory、java.lang.OutOfMemoryError: Java heap space 或系统级 Killed），本质是任务进程申请内存超出了可用资源上限。这不是单一配置能解决的问题，需分层应对：从构建脚本、Runner 资源分配，到宿主机与容器限制，逐级收紧或扩容。
针对不同构建环境调大进程内存上限
Node.js、Maven、Gradle 等工具默认内存限制偏低，需显式放宽：
-
前端项目（Vue/React）：在
package.json的构建脚本中加入NODE_OPTIONS，例如："build": "cross-env NODE_OPTIONS=\"--max_old_space_size=4096\" vue-cli-service build"
（4096表示 4GB；cross-env保证跨平台生效） -
Maven 项目：在
.gitlab-ci.yml的before_script或具体 job 中设置环境变量：MAVEN_OPTS: "-Xms2g -Xmx4g -XX:MaxMetaspaceSize=1g"
注意：必须在 job 环境中显式传入，不能只依赖 Runner 宿主机的全局环境变量 -
Java/Gradle 项目：同理，在
script步骤前导出：- export GRADLE_OPTS="-Xmx4g -XX:MaxMetaspaceSize=1g"
限制并发与优化 Runner 资源分配
高并发会快速耗尽系统内存，尤其当多个构建任务同时执行大型打包或测试时：
- 编辑 Runner 的
config.toml，将concurrent值设为不超过宿主机 CPU 核心数的一半（例如 4 核机器设为2），避免争抢内存和 I/O - 为每个 executor（如
docker）配置内存限制：[runners.docker]<br> memory = "4g"<br> memory_swap = "6g"
防止单个 job 吃光全部资源 - 启用
oom_kill_disable = false（默认），让内核在内存不足时终止最占内存的容器，而非卡死整个 Runner
规避构建过程中的内存放大操作
某些操作看似简单，实则隐含巨大内存开销：
- 避免在 CI 中
git add .或git commit大体积文件（如打包产物、日志、tar.gz）——Git 会将其完整载入内存做对象计算；应通过.gitignore排除，或改用artifacts机制上传 - 禁用不必要的构建步骤：例如跳过未改动模块的测试（
--only-changed）、关闭 source map 生成（productionSourceMap: false）、压缩图片前先检查尺寸阈值 - Docker 构建时使用多阶段（multi-stage）：基础镜像安装依赖与构建工具，最终镜像仅复制产出物，大幅减少层体积与构建时内存压力
监控与诊断：让问题可定位
不加监控的调优等于盲调。建议在关键 job 中嵌入轻量诊断：
- 在
before_script加入：- free -h && echo "---" && docker stats --no-stream --format "table {{.Name}}\t{{.MemUsage}}\t{{.CPUPerc}}" 2>/dev/null || echo "no docker" - 对 Node.js 项目，可在构建命令后追加
node --v8-options | grep max_old_space_size验证参数是否生效 - 开启 GitLab 的 job 日志截断预警（默认 4MB），配合降低并发，可提前暴露内存紧张趋势
