最常见的原因是未指定-XX:HeapDumpPath，JVM默认写入当前工作目录，而生产环境常因权限不足、路径只读或磁盘满导致静默失败；必须显式指定可写且有足够空间的绝对路径。
为什么加了 -XX:+HeapDumpOnOutOfMemoryError 却没生成 dump 文件
最常见原因是 JVM 启动时没指定 dump 存放路径，JVM 默认会尝试写到当前工作目录（user.dir），而生产环境的启动脚本往往以非 root 用户运行，且工作目录可能是 /、/tmp 或只读路径，导致权限拒绝或磁盘满失败。JVM 不会报错提示，只是静默跳过 dump 生成。
- 必须显式用
-XX:HeapDumpPath=/path/to/dumps指定可写、有足够空间的目录（如/var/log/myapp/heapdumps） - 确保该路径对 JVM 进程用户（如
appuser）可写：chown appuser:appuser /var/log/myapp/heapdumps && chmod 755 /var/log/myapp/heapdumps - 避免用相对路径或
~，JVM 不解析 shell 展开，-XX:HeapDumpPath=~/dumps会真的试图创建名为~的目录 - 如果容器化部署（如 Docker），需挂载宿主机目录并确认 UID 匹配，否则即使路径存在也会因权限被拒
-XX:HeapDumpPath 支持动态命名吗？怎么区分多次 OOM 的 dump 文件
不支持自动时间戳或 PID 插入，JVM 原生只接受一个固定路径或文件名。若指定为目录，每次 OOM 都会覆盖同名文件 java_pid<pid>.hprof</pid>；若指定为完整文件名（如 -XX:HeapDumpPath=/dumps/oom.hprof），后续 OOM 会直接失败（因文件已存在）。
- 推荐指定为目录（如
-XX:HeapDumpPath=/var/log/myapp/heapdumps/），再配合外部脚本轮转 —— JVM 生成的是java_pid12345.hprof，PID 天然唯一，已具备区分能力 - 不要手动重命名正在生成的 dump 文件（如
mv java_pid12345.hprof oom_20240520.hprof），JVM 可能写入中断或损坏 - 如需带时间标记，应在 dump 生成后由监控脚本处理，例如用 inotifywait 监听目录，触发
mv java_pid*.hprof heap_$(date +%Y%m%d_%H%M%S)_$PID.hprof
除了 HeapDumpOnOutOfMemoryError，还有哪些参数影响 dump 效果
单靠开启开关远远不够。dump 文件是否完整、能否用于分析，取决于 JVM 是否来得及完成写入，以及堆数据是否被 GC 干扰。
- 务必加上
-XX:+PrintGCDetails -Xloggc:/var/log/myapp/gc.log：OOM 前 GC 日志能帮你判断是内存泄漏还是配置过小，避免盲等 dump - 慎用
-XX:+UseGCOverheadLimit：它可能在真正 OOM 前就 kill 进程，导致 dump 不触发（因为不是OutOfMemoryError抛出） - 如果应用使用 G1，建议加
-XX:G1HeapRegionSize=1M（按需）：大堆下 region size 过大会导致 dump 写入变慢，增加进程卡死风险 - 避免和
-XX:+DisableExplicitGC共用：某些老框架（如早期 Spring Boot Admin）会主动调System.gc()触发 dump 前清理，禁用后反而让 dump 更“脏”
容器环境下 dump 文件生成失败的典型表现和验证方法
容器里看不到 dump，90% 是路径、权限、空间三者之一出问题，而不是 JVM 参数本身错了。错误现象往往很隐蔽：日志里没有 java.lang.OutOfMemoryError 的完整堆栈，或者只有堆栈但无 dump 文件。
- 启动后立刻检查 JVM 实际参数：
ps -ef | grep java | grep HeapDump，确认-XX:HeapDumpPath出现在命令行中，且路径拼写正确（注意空格和引号） - 进容器手动模拟写入：
su - appuser -c "echo test > /var/log/myapp/heapdumps/test.txt"，验证权限和路径可达性 - 强制触发一次 OOM 测试（仅限测试环境）：
curl -X POST http://localhost:8080/actuator/heapdump（Spring Boot Actuator）或用jmap -dump:format=b,file=/tmp/test.hprof <pid>看是否能写成功 - 注意容器
rootfs磁盘配额（docker run --storage-opt size=10G）：即使宿主机空间充足，容器层也可能满，df -h要在容器内执行
dump 文件体积通常等于堆大小（比如 4G 堆 → 4G hprof），别指望它很小；生成过程会卡住应用几秒到几十秒，这期间请求会超时，得提前跟运维对齐影响范围。
