oom时自动导出需配置-xx:+heapdumponoutofmemoryerror和可写绝对路径的-xx:heapdumppath；非oom僵死则用jmap -dump:format=b,file=手动抓取；分析首选mat的leak suspects与dominator tree，注意路径权限、文件覆盖、版本兼容及gc日志配套。
面试中问到内存溢出时的 JVM Dump 导出策略，核心是考察你是否具备线上问题“留痕—定位—归因”的闭环能力。不是背参数，而是清楚什么场景用什么方式、为什么这么配、有哪些坑。
OOM 自动触发 dump（生产首选）
这是最可靠、最不依赖人工干预的方式，适用于堆内存溢出（java.lang.OutOfMemoryError: Java heap space）场景：
- -XX:+HeapDumpOnOutOfMemoryError：开启 OOM 时自动生成堆转储
- -XX:HeapDumpPath=/path/to/dumps/：指定 dump 文件保存目录（推荐绝对路径，确保目录存在且 JVM 进程有写权限）
- 可选加 -XX:HeapDumpBeforeFullGC（JDK8u191+）用于提前捕获 Full GC 前状态，辅助判断是否已濒临崩溃
注意：该机制只对堆溢出生效，对 Metaspace、Direct Memory、栈溢出等无效；同时需确保磁盘空间充足，.hprof 文件常达数 GB。
服务僵死但未报 OOM 时的手动导出
当进程响应极慢、CPU 高但无 OOM 日志，怀疑内存堆积或 GC 恶性循环时，用 jmap 主动抓快照：
-
jmap -dump:format=b,file=app.hprof <pid></pid>：最常用，生成标准 hprof 格式 - 若进程卡死严重，加 -F 强制执行：
jmap -F -dump:format=b,file=app.hprof <pid></pid> - 避免在高负载时频繁执行，jmap 全局 stop-the-world，可能加剧服务不可用
操作前先用 ps aux | grep java 或 jps -l 确认目标 pid；如容器部署，需进入容器内执行或通过 docker exec 调用。
Dump 文件分析工具与关键动作
导出只是第一步，面试官常会追问“拿到 dump 后怎么快速聚焦问题”：
- 优先用 Eclipse MAT（Memory Analyzer Tool），尤其
Leak Suspects Report和Dominator Tree视图 - 关注 “Retained Heap” 最大的几个类，再右键 → Path to GC Roots（排除弱/软引用），看谁长期持有着它们
- 结合线程视图（
Thread Overview）查耗时长、对象创建密集的线程，比对业务代码入口（如 Controller 方法、定时任务） - 若 dump 过大（>4GB），MAT 启动易失败，改用命令行解析：
./ParseHeapDump.sh app.hprof org.eclipse.mat.api:suspects
避坑要点（面试加分项）
光会配置不够，真实环境容易踩的雷才是区分经验的关键：
- 不要只设
-XX:HeapDumpPath=xxx.hprof—— 这会导致每次 OOM 覆盖旧文件，应设为目录，JVM 自动按时间戳命名 - JDK 版本兼容性：JDK 8 推荐 MAT 1.11.0；JDK 17+ 可用最新 MAT，但需确认是否支持 ZGC/Shenandoah 的 dump 格式
- 容器环境注意挂载卷权限：/data/dump 目录在宿主机映射后，容器内 UID 可能无写入权限，导致 dump 失败且无声无息
- 避免在启动脚本里漏掉
-XX:+PrintGCDetails -Xloggc:gc.log—— GC 日志和 dump 必须配套分析，单看 dump 很难判断是泄漏还是瞬时高峰
