遇到Jenkins构建时内存溢出，我一般不会马上改全局JVM参数，而是先翻日志确认OOM到底出在哪一层。这个判断很重要，因为Jenkins主进程和构建任务子进程的内存设置是两套体系，调错方向等于白忙。
先确认OOM发生在哪一层
如果构建过程中出现OutOfMemoryError，先区分是Jenkins主进程还是构建任务自身溢出。检查Jenkins系统日志或控制台输出，错误信息中通常带有“Java heap space”或“GC overhead limit exceeded”字样。若错误出现在构建脚本或编译环节，则更可能是Maven、Gradle等子进程内存不足；若错误出现在Jenkins页面或插件执行时，则要优先排查Jenkins主服务的内存设置。这种区分决定后续调整的方向，避免盲目修改全局参数。
实际操作中，我会先看控制台输出里的堆栈是Maven的，还是Jenkins自身的。如果堆栈里出现hudson.remoting或jenkins包名，基本可以断定是主进程问题。如果看到org.codehaus.plexus.classworlds.launcher.Launcher，那就是Maven子进程在报错。
容易误判的地方
最常见的误判是只调大Jenkins主进程堆内存，但构建脚本里跑的Maven或Gradle仍然沿用默认的256m或512m。原本编译一次只需要1GB，系统却把2GB都给了主服务，子进程照样溢出。另一个误判是把系统可用内存当成Jenkins可用的内存，忘了机器上还有数据库、Docker、监控Agent在占用。
还有一种情况是Pipeline脚本中通过sh 'mvn clean package'执行构建，这时候Maven的环境变量可能来自Jenkins全局配置，也可能被脚本里的export覆盖，所以要打印出实际值才能判断。
调整Jenkins主进程的内存参数
调整Jenkins主进程堆内存，需要修改Jenkins服务启动参数。在Linux系统中，一般编辑/etc/sysconfig/jenkins或systemd服务文件，找到JENKINS_JAVA_OPTIONS变量，将-Xmx值调大，比如改为-Xmx2048m或更高。修改后重启Jenkins服务才生效。注意，如果使用容器方式部署，应修改环境变量JAVA_OPTS。调整前先查看当前内存占用，用free -m或jmap -heap确认实际使用情况，避免设置过大导致物理内存不足。
这里要提醒两点：第一，重启Jenkins会让正在跑的构建任务中断，尽量选在构建较少的时间段操作；第二，如果系统里还有其他Java应用，别把-Xmx填满所有空闲内存。通常建议先看当前堆使用峰值，再按峰值的一点五倍设置，而不是随便翻一倍。
构建任务子进程的内存独立配置
构建任务中的Maven或Gradle子进程有自己独立的JVM参数，即使调大Jenkins主进程，也无法解决编译期OOM。在Jenkins的Maven配置中，可以设置MAVEN_OPTS，例如“-Xmx1024m -XX:MaxMetaspaceSize=512m”，Gradle则通过GRADLE_OPTS或build.gradle中的jvmArgs调整。这些参数只影响单个构建任务，不会影响Jenkins系统本身。常见坑是只改Jenkins全局设置，忽略了工具链的独立内存限制，导致问题依旧。
对于Maven，可以在Jenkins的“全局工具配置”里找到Maven安装项，在“全局MAVEN_OPTS”中填入参数。也可以在Pipeline脚本里用withEnv(['MAVEN_OPTS=-Xmx1024m']) { sh 'mvn package' }的方式做局部覆盖。Gradle类似，但要注意GRADLE_OPTS和JAVA_OPTS的优先级，如果build.gradle里配置了jvmArgs，命令行参数可能被覆盖。
另外，如果使用的是Jenkins的Docker插件或Kubernetes插件，每个构建任务跑在独立容器里，那就要修改容器镜像里的JVM参数，或者通过环境变量注入。这种情况下，Jenkins主进程的内存设置和构建任务完全隔离，不能用传统方式管理。
验证参数是否生效
修改完参数，不能只看配置界面，要确认实际进程真的拿到了这些参数。修改Jenkins启动参数后，需要确认配置是否被正确读取。可以用ps -ef | grep jenkins检查实际进程的命令行，看-Xmx是否生效。另一个常见坑是Jenkins通过反向代理或服务包装器启动时，可能有两处配置，一处失效而另一处生效。如果在Pipeline脚本中使用sh 'mvn test'，Maven会继承Jenkins进程的环境变量，但也可能被自己脚本中的export覆盖。建议先在构建脚本里用echo ${MAVEN_OPTS}打印出实际值，再逐步排查。
除了看命令行，还可以在构建过程中用jstat -gcutil <pid>观察堆使用曲线。如果设置的是1GB，但GC后堆始终在900MB附近波动，说明还可能不够；如果堆占用稳定在300MB左右，说明1GB有富余。
调整的边界与后续维护
盲目调大内存可能导致系统SWAP频繁或进程被OOM Killer杀掉。在调整前，需要评估Jenkins所在机器的物理内存和已有服务占用。给Jenkins主进程分配的内存建议不超过物理内存的一半，同时为操作系统和其他服务预留空间。若构建任务数量多且并发高，应该考虑分散到多个节点上，而不是单机无限堆内存。另一种做法是限制每个构建任务的内存上限，利用Docker容器或Linux cgroup隔离资源，这样即便某个任务耗尽内存也不会拖垮整个Jenkins。
后续维护时，我建议把OOM出现的频率和堆内存设置记录下来，作为后续调整的参考。每次改完参数，至少观察一两个完整构建周期，确认没有反复。如果加大堆内存后仍然溢出，就要怀疑代码里是否有内存泄漏，比如插件长期持有对象、构建脚本生成超大集合等。这时应该用jmap -dump导出一份堆转储分析，而不是继续上调-Xmx。
如果已经调整过多次，堆内存加到4GB甚至8GB还是溢出，那就要认真审视构建任务本身的资源需求。有些大型前端项目或Android编译任务，单靠调整JVM参数无法根治，需要拆分成更小的构建单元，或者用独立的构建机来跑。
最后提醒一句：-XX:+UseG1GC和-XX:MaxGCPauseMillis这类垃圾收集器参数可以缓解停顿，但不要指望它们替代内存配置。G1收集器适合大堆场景，如果堆只有512MB，用G1反而可能增加开销。参数调整要结合具体构建任务特点，逐步验证，不要一次性堆上所有优化项。