必须配齐-XX:+HeapDumpOnOutOfMemoryError、-XX:HeapDumpPath（绝对路径且权限正确）、GC日志参数，并验证目录可写、磁盘充足、文件生成有效；推荐路径不带.hprof后缀，用%p避免多实例覆盖，上线前须用测试代码触发OOM验证。
Java 生产环境发生 OOM 时，要让 JVM 自动保存堆快照，不能只加一个参数就以为万事大吉。关键在于配置完整、路径可靠、权限到位、验证有效。
必须启用的核心参数组合
仅开启 -XX:+HeapDumpOnOutOfMemoryError 是不够的，它只是“触发开关”。真正能落地生成文件，需同时配齐：
-
-XX:HeapDumpPath=/data/dumps/：指定绝对路径（不能用
~/或相对路径），目录需提前创建；推荐结尾不带.hprof，JVM 会自动生成java_pid12345.hprof，避免多实例覆盖 - -XX:+PrintGCDetails -Xlog:gc*:file=/var/log/myapp/gc.log（JDK 9+）或 -verbose:gc -Xloggc:/var/log/myapp/gc.log（JDK 8）：GC 日志与 dump 时间对齐，可还原 OOM 前内存行为
- -XX:+ExitOnOutOfMemoryError（推荐）：OOM 后立即退出进程，防止服务处于不可靠状态，尤其适合容器化部署
路径与权限的实操要点
大量线上配置失败，问题都卡在路径上：
- Kubernetes 环境中避免用
/tmp（tmpfs 小且易丢），应挂载持久卷到明确路径，如/data/dumps - 用
ps -o user= -p $(pgrep -f MyApplication)查 Java 进程运行用户，再执行ls -ld /data/dumps确认该用户有写权限 - JVM 不会自动创建父目录，必须提前执行：
mkdir -p /data/dumps && chown appuser:appuser /data/dumps
应对大堆与磁盘压力的策略
堆设为 4GB+ 时，dump 文件可能接近堆上限，需提前规划：
立即学习“Java免费学习笔记（深入）”；
- 确保
/data/dumps所在磁盘空间充足，并将df -h /data加入监控告警 - 用脚本定期清理旧 dump：
find /data/dumps -name "*.hprof" -mtime +7 -delete - 启用压缩优化：64 位 JVM 默认开启 -XX:+UseCompressedOops，可减小 dump 体积；G1 GC 下可调 -XX:G1HeapRegionSize=2M 提升回收效率
上线前必须做的验证动作
别等真实故障才确认是否生效：
- 写个简易测试接口，循环分配大数组（如
new byte[100 * 1024 * 1024]），快速触发OutOfMemoryError: Java heap space - 观察日志是否输出
java.lang.OutOfMemoryError，并检查/data/dumps/是否生成了.hprof文件 - 用
file /data/dumps/java_pid*.hprof验证文件格式是否为 “Java HotSpot(TM) … hprof binary file”
