必须配齐-XX:+HeapDumpOnOutOfMemoryError、-XX:HeapDumpPath=/data/dumps/和GC日志参数，结合持久化存储、权限配置及磁盘风控措施，否则dump将静默失败或引发Pod驱逐。
单独加 -XX:+HeapDumpOnOutOfMemoryError 在容器里基本没用——它只是个开关，不配路径、权限、日志和验证，dump 很可能静默失败，甚至引发磁盘打满、Pod 驱逐。
必须配齐的三个核心参数
生产级配置不是只写一个参数，而是组合落地：
- -XX:+HeapDumpOnOutOfMemoryError：触发开关，必须开启
-
-XX:HeapDumpPath=/data/dumps/：绝对路径，末尾带斜杠表示目录；JVM 自动命名成
java_pid12345.hprof，PID 天然去重；禁用~/dumps或相对路径（JVM 不解析~） - -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 前内存增长轨迹
容器环境路径与权限硬约束
90% 的“没生成”问题出在路径写入失败，而非参数错误：
- 避免用
/tmp：它是 tmpfs，空间小、重启即丢；应挂载独立 PV（如 hostPath/NFS），路径明确如/data/dumps - 启动前执行：
mkdir -p /data/dumps && chown appuser:appuser /data/dumps && chmod 755 /data/dumps；用ps -o user= -p $(pgrep -f MyApp)确认进程用户 - Kubernetes 中必须声明 volumeMount + persistentVolumeClaim，否则容器重启后 dump 全丢
防堆积与磁盘风险管控
大堆应用一次 dump 可达数 GB，OOM 频发时极易打爆磁盘：
- 推荐固定文件名覆盖策略：
-XX:HeapDumpPath=/data/dumps/oom.hprof，防止多份堆积；若需保留多份，须配合外部脚本按时间戳重命名 - 启动 entrypoint 中加入磁盘余量检查：
df -h /data/dumps | awk 'NR==2 {print $5}' | sed 's/%//'，低于阈值（如 20%）则拒绝启动 - 搭配轮转清理：
find /data/dumps -name "*.hprof" -mtime +7 -delete，避免长期占用
上线前有效性验证不可跳过
别等线上 OOM 才发现配置失效。主动验证一次，比事后排查省三天：
- 写临时接口，循环分配大数组：
new byte[1024 * 1024 * 100]，快速触发堆耗尽 - 观察 GC 日志是否输出 OOM 异常，同时检查
/data/dumps/是否生成.hprof文件 - 用
file java_pid*.hprof或head -c 100 java_pid*.hprof | hexdump -C确认文件格式有效（开头应为PHD\0或类似堆快照标识）
