根本原因是jvm未进入java层oom处理流程，常见于堆外内存耗尽、oom killer强杀或jvm崩溃等系统级异常；该参数仅在java堆真正耗尽且jvm成功触发oom逻辑时才生效。
为什么加了 -XX:HeapDumpOnOutOfMemoryError 却没生成 dump 文件
根本原因不是参数没生效，而是 JVM 从触发 OOM 到进程退出之间，可能根本没机会写完 dump。常见于：堆外内存耗尽、系统 OOM Killer 强杀、JVM 自身崩溃（如 SIGSEGV）这三类情况——它们压根不会走 Java 层的 OOM 流程，-XX:HeapDumpOnOutOfMemoryError 完全不触发。
真正能捕获到 heap dump 的，仅限于「Java 堆内存真正耗尽 + JVM 成功进入 OOM 处理逻辑」这一窄带场景。所以第一步必须确认：你看到的 Exit Code: 137 或 Killed process java 日志，是不是来自内核 OOM Killer？如果是，dump 参数再全也没用。
- 查
/var/log/messages或/var/log/syslog，搜Out of memory: Killed process.*java - 查 JVM 工作目录或
-XX:HeapDumpPath=指定路径，看有没有.hprof文件生成 - 如果两者都空，优先怀疑是系统级杀进程，而非 JVM 堆溢出
HeapDumpPath 路径配置的三个关键陷阱
-XX:HeapDumpPath 看似简单，但线上最容易栽在权限、路径存在性和磁盘空间三处。
- 路径必须**提前创建好**，且 JVM 进程用户（如
java用户）有写权限；JVM 不会自动创建多级目录 - 避免用相对路径（如
-XX:HeapDumpPath=./dumps），工作目录可能随启动方式变化；推荐绝对路径，例如-XX:HeapDumpPath=/data/java-dumps/ - 目标磁盘剩余空间必须 ≥ 当前堆最大值（
-Xmx），否则 dump 写到一半就失败，文件残缺不可读
验证方式：手动 touch 一个同名大文件测试写入，比如 dd if=/dev/zero of=/data/java-dumps/test.hprof bs=1M count=2048。
配合 -XX:+PrintGCDetails 能定位 dump 是否“来得及”
单独开 dump 参数，无法判断 JVM 在 OOM 前是否已濒临瘫痪。加上 GC 日志后，能交叉验证 dump 生成时机是否合理。
- 如果日志里反复出现
Full GC (Ergonomics)或GC overhead limit exceeded，说明 JVM 已经在垂死挣扎，此时即使生成 dump，内容也大概率不完整 - 如果 dump 文件大小远小于
-Xmx（比如-Xmx4g但 dump 只有 500MB），基本可断定是 GC 频繁卡住、写入被中断 - 建议搭配使用：
-XX:+PrintGCDetails -Xloggc:/data/logs/gc.log -XX:+UseGCLogFileRotation -XX:NumberOfGCLogFiles=5 -XX:GCLogFileSize=10M
容器环境（K8s）下 dump 文件的落盘与提取
在 Pod 里生成的 dump 文件，不能只靠 kubectl exec 进去 ls —— 容器重启后文件就丢了。必须确保 dump 写到持久卷或宿主机路径。
- 不要把
-XX:HeapDumpPath指向容器 rootfs 内的临时路径（如/tmp或/app） - 通过 volumeMount 将宿主机目录（如
/mnt/dumps）挂载进容器，然后设为-XX:HeapDumpPath=/mnt/dumps/ - 提取时用
kubectl cp <namespace>/<pod-name>:/mnt/dumps/xxx.hprof ./</pod-name></namespace>，而不是依赖容器内 shell - 注意：部分 K8s 发行版（如 OpenShift）默认禁用
kubectl cp，需提前开通securityContext权限
最常被忽略的一点：dump 文件体积动辄数 GB，上传过程容易超时或中断，建议先用 gzip 压缩再传，或者直接在节点上用 scp 拉取。
