启用-XX:+HeapDumpOnOutOfMemoryError并配置可写绝对路径的-XX:HeapDumpPath，可使Java进程OOM时自动保存Heap Dump；非OOM时可用jmap -dump:format=b,file=...手动导出，注意权限与live参数优化体积。
Java进程OOM时自动保存Heap Dump的JVM参数
Java程序因内存溢出崩溃时，默认不会生成Heap Dump，必须显式配置JVM启动参数才能触发自动导出。关键不是“能不能”，而是-XX:+HeapDumpOnOutOfMemoryError是否启用，以及-XX:HeapDumpPath路径是否可写。
-
-XX:+HeapDumpOnOutOfMemoryError必须开启，否则即使OOM也静默退出 -
-XX:HeapDumpPath=/path/to/dumps建议指定绝对路径，相对路径会基于JVM启动目录解析，容易因服务部署方式（如systemd、Docker）导致写入失败 - 路径需对运行Java进程的用户有写权限，常见坑是设在
/var/log但Java以非root用户运行，或Docker容器内挂载点未授权 - 如果路径末尾带
.hprof（如-XX:HeapDumpPath=/dumps/oom.hprof），每次OOM都会覆盖同名文件；不带后缀则自动生成时间戳文件（如java_pid12345.hprof）
非OOM场景下手动触发Heap Dump的可靠方式
很多问题不是OOM，而是长期运行后GC变慢、对象堆积——这时需要主动抓取堆快照。最稳妥的是用jmap，但要注意进程状态和权限。
- 先确认目标进程ID：
jps -l或pgrep -f "MyApplication" - 执行导出：
jmap -dump:format=b,file=/tmp/heap.hprof <pid>，注意format=b不能省略，否则可能输出文本而非二进制hprof - 若报
Unable to open socket file，通常是目标JVM启用了-XX:+DisableAttachMechanism，或运行在容器中未共享/tmp（Java 8u191+默认限制attach） - 生产环境慎用
jmap -histo或jmap -finalizerinfo，它们会触发Full GC，可能引发STW抖动
Spring Boot应用在Kubernetes中配置Heap Dump的注意事项
K8s里Java进程常被封装在容器中，自动导出路径、存储卷、信号处理都得重新对齐。
- JVM参数要写进
args或JAVA_TOOL_OPTIONS环境变量，不能只改application.properties -
-XX:HeapDumpPath必须指向一个已挂载的EmptyDir或PersistentVolume路径，比如/workspace/dumps，且容器启动时该目录需存在并可写 - 避免用
/tmp：某些基础镜像（如distroless）没有/tmp，或K8s securityContext禁止写入 - OOM Killer杀掉容器时，JVM可能没机会写完hprof，所以建议同时配
-XX:+ExitOnOutOfMemoryError加快退出，减少截断风险
Heap Dump文件太大导致写入失败或分析卡死
导出成功不等于能用，大堆（>4GB）在磁盘IO慢或内存小的机器上极易出问题。
立即学习“Java免费学习笔记（深入）”；
- 导出时磁盘剩余空间至少是堆大小的1.5倍，hprof是压缩前的原始对象图，实际文件可能比-Xmx还大
- 用
jmap -dump:format=b,live,file=...中的live参数可只导出存活对象，跳过GC Roots不可达的垃圾，显著减小体积 - 分析端别直接用VisualVM打开超大hprof，优先用
jhat或Eclipse MAT的“Parse Heap Dump”后台解析，或用hprof-conv（Android SDK工具）做轻量过滤 - 如果频繁OOM且dump巨大，说明问题不在单次泄漏，而可能是元空间泄漏（检查
-XX:MaxMetaspaceSize）、直接内存（-XX:MaxDirectMemorySize）或native memory，这些都不会出现在heap dump里
真正麻烦的不是配不出dump，而是dump出来之后发现根本打不开，或者打开一看全是char[]和String——这时候得回头确认是不是忘了加live，或者压根儿该去看GC日志和jstack线程栈。
