关键第一步是让jvm自动捕获现场信息：启用-xx:+heapdumponoutofmemoryerror并指定heapdumppath，配合printgcdetails记录gc日志；针对metaspace、direct memory、线程等不同oom类型分别设置maxmetaspacesize、maxdirectmemorysize和xss参数；统一-xms与-xmx值并启用g1 gc以稳定运行环境。
Java 内存溢出（OutOfMemoryError）发生时，光靠重启或加内存不能治本。关键第一步是让 JVM “说话”——通过合理配置启动参数，自动捕获现场信息，为后续分析提供依据。
启用堆转储自动保存
当堆内存耗尽触发 java.lang.OutOfMemoryError: Java heap space 时，需立即保留内存快照：
- 添加参数：-XX:+HeapDumpOnOutOfMemoryError，让 JVM 在 OOM 瞬间生成 .hprof 文件
- 指定路径：-XX:HeapDumpPath=/opt/dumps/（确保目录存在且进程有写权限）
- 建议配合 -XX:+PrintGCDetails -Xlog:gc*:gc.log:time，记录 GC 行为与时间戳，便于关联分析
限制并监控元空间使用
若报错是 java.lang.OutOfMemoryError: Metaspace，说明类加载过多（如频繁热部署、大量动态代理）：
- 设置上限：-XX:MaxMetaspaceSize=256m（避免无节制占用本地内存）
- 可选预分配：-XX:MetaspaceSize=128m，减少首次扩容带来的停顿
- 搭配 -XX:+PrintGCDetails，观察 Metaspace GC 是否频繁，判断是否需优化类加载逻辑
防范直接内存与线程资源耗尽
两类易被忽略的 OOM 场景，需针对性设限：
-
Direct buffer memory：NIO 使用
ByteBuffer.allocateDirect()时，受 -XX:MaxDirectMemorySize=512m 控制（默认等于 -Xmx） - unable to create new native thread：线程数爆炸常因 -Xss 过大或系统级限制；建议设为 -Xss256k（而非默认 1MB），并检查 ulimit -u
统一堆大小并启用 G1 收集器
稳定诊断的前提是减少干扰变量：
- 固定堆容量：-Xms4g -Xmx4g（避免运行中伸缩引发 GC 波动）
- 选用现代 GC：-XX:+UseG1GC -XX:MaxGCPauseMillis=200，兼顾吞吐与响应，G1 日志更易读
- 禁用 GC 开销限制（临时）：-XX:-UseGCOverheadLimit，防止因 GC 频繁提前抛出误导性异常
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
