必须配齐-XX:+HeapDumpOnOutOfMemoryError、-XX:HeapDumpPath（绝对路径且权限正确）、GC日志参数，否则dump可能无法生成或无效；还需验证路径可写、磁盘充足，并用测试触发确认.hprof文件成功生成且格式有效。
光加 -XX:+HeapDumpOnOutOfMemoryError 不够，它只是“触发开关”，不是“完整方案”。生产环境要确保 dump 文件真能生成、位置明确、内容可用，必须配套路径、权限、日志和验证四方面落地。
必须配齐的三个核心参数
单独启用该参数在生产中基本等于没开——JVM 不报错，但 dump 往往静默失败。
-
-XX:HeapDumpPath=/data/dumps/：必须用绝对路径，末尾带斜杠表示目录；JVM 会自动生成
java_pid12345.hprof，PID 天然去重 - -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:+HeapDumpBeforeFullGC（推荐）：不等 OOM，每次 Full GC 前都存一份 dump，对渐进式泄漏更敏感
路径与权限的硬性要求
90% 的“没生成”问题出在这里，不是参数写错，而是 JVM 根本写不进去。
- 容器环境（如 Kubernetes）避免用
/tmp，它常是 tmpfs，空间小且重启即丢；应挂载持久卷到明确路径，例如/data/dumps - 提前执行：
mkdir -p /data/dumps && chown appuser:appuser /data/dumps && chmod 755 /data/dumps（用ps -o user= -p $(pgrep -f MyApp)确认进程用户） - 禁用
~/dumps或相对路径（如./dumps），JVM 不解析 shell 展开，会直接创建名为~的目录
dump 文件的大小与管理
大堆（>4GB）生成的 hprof 文件可能超 10GB，影响磁盘和后续分析效率。
立即学习“Java免费学习笔记（深入）”；
- 搭配
-XX:+UseG1GC -XX:G1HeapRegionSize=2M（按堆大小调整），提升 G1 回收效率，间接减小 dump 体积 - 64 位 JVM 默认开启
-XX:+UseCompressedOops，减少对象指针开销，压缩 dump 尺寸 - 用外部脚本轮转清理：
find /data/dumps -name "*.hprof" -mtime +7 -delete，避免磁盘打满
上线前必须做的有效性验证
别等线上 OOM 才发现配置失效。主动测试一次，比事后排查省三天。
- 写个临时接口，循环分配大数组：
new byte[1024 * 1024 * 100]，快速触发堆耗尽 - 观察日志是否输出
java.lang.OutOfMemoryError: Java heap space - 检查目标目录是否生成
.hprof文件，并用file /data/dumps/java_pid*.hprof验证格式（应显示 “Java Heap Dump”）
