-XX:+HeapDumpOnOutOfMemoryError在发生java.lang.OutOfMemoryError: Java heap space时触发，暂停应用线程并生成hprof格式堆转储文件，需配合-XX:HeapDumpPath指定路径及权限，仅对堆溢出有效，不适用于Metaspace等其他OOM类型。
-XX:+HeapDumpOnOutOfMemoryError 并不会让 JVM “崩溃”，而是当发生 OutOfMemoryError（尤其是堆内存耗尽）时，主动触发一次完整的堆内存快照（heap dump）保存到磁盘，便于后续分析。JVM 仍会按默认行为抛出异常并终止当前线程（如主线程退出导致进程结束），但这个过程是受控的、可诊断的，不是“随机崩溃”。
它在什么时机生效？
该参数只对以下情况有效：
- 抛出
java.lang.OutOfMemoryError: Java heap space（最常见） - 不适用于
Metaspace、Direct buffer memory或栈溢出等其他 OOM 类型（需配合其他参数，如-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=...仅管堆；元空间需额外配置） - 必须发生在 JVM 尝试分配对象失败、且 GC 后仍无法腾出足够空间时
它怎么保存堆现场？
触发后，JVM 会：
- 暂停所有应用线程（Stop-The-World）
- 遍历整个堆，序列化所有存活对象的引用关系、类信息、字段值等
- 以
hprof格式写入文件（二进制，可用 JVisualVM、Eclipse MAT 等工具打开） - 默认路径为 JVM 启动目录，文件名形如
java_pid<pid>.hprof</pid>
怎么用才真正有用？
单靠 +HeapDumpOnOutOfMemoryError 不够，必须搭配路径和权限控制：
立即学习“Java免费学习笔记（深入）”；
- 指定存储位置：
-XX:HeapDumpPath=/path/to/dumps/（建议用绝对路径，确保目录存在且 JVM 进程有写权限） - 避免被覆盖：可加时间戳，如
-XX:HeapDumpPath=/dumps/oom_%p_%t.hprof（%p是 PID，%t是时间戳） - 确认磁盘空间充足——一个大堆 dump 可能达数 GB
- 生产环境建议配合
-XX:+PrintGCDetails -Xloggc:gc.log，把 GC 行为和 OOM 上下文关联分析
它不能替代什么？
这个参数只是“事后取证”手段：
- 不能防止 OOM 发生，也不能自动扩容或回收内存
- 不能反映 OOM 前的内存增长趋势——需结合监控（如 Prometheus + JVM Exporter）或定期 jmap 采样
- dump 文件本身不包含线程栈、锁状态、JNI 引用等完整上下文，必要时需同时保留
jstack输出
