大促必须开启HeapDumpOnOutOfMemoryError：OOM时自动保存堆快照，含完整对象图与GC Roots，配合命名规则和权限配置，确保故障现场可追溯；搭配MAT快速定位泄漏源，并通过告警脚本与磁盘保护提升可靠性。
大促期间应用突然崩溃，最怕的不是报错，而是重启后现场没了——查不出谁占了内存、谁没释放、哪段代码在“悄悄吃内存”。HeapDumpOnOutOfMemoryError 就是专为这种高危时刻设计的“自动快照开关”，它不靠人盯、不靠运气，只要配置到位，OOM 一发生，堆内存状态就立刻落盘，相当于给崩溃瞬间按下了暂停键。
为什么大促必须开这个开关？
大促流量尖峰会放大所有潜在问题：缓存雪崩、日志刷屏、临时对象暴增、线程池撑满……这些都可能在几秒内耗尽堆内存。人工干预根本来不及，而默认 JVM 不会保存任何现场。开启该参数后：
- OOM 触发时自动写入 .hprof 文件，无需人工介入，避免“想 dump 但进程已死”的尴尬
- 文件包含完整对象图、GC Roots 引用链、各代内存分布，是定位泄漏的唯一可信依据
- 配合时间戳（%t）和 PID（%p）命名，可精准对应监控告警时间点，快速串联故障链
生产环境安全配置要点
不能只加个 -XX:+HeapDumpOnOutOfMemoryError 就完事，否则可能因路径不可写、磁盘写满或权限不足导致 dump 失败：
- 指定可写路径：
-XX:HeapDumpPath=/data/app/heapdumps/heapdump_%t_%p.hprof - 提前创建目录并授权：
mkdir -p /data/app/heapdumps && chown appuser:appgroup /data/app/heapdumps - 限制单次 dump 大小（可选）：通过
-XX:MaxHeapFreeRatio和合理堆上限（如-Xmx4g）防止 dump 文件过大拖垮磁盘 - 搭配 GC 日志：
-Xloggc:/data/app/logs/gc.log -XX:+PrintGCDetails，便于交叉验证是否长期 Full GC 后仍无法回收
拿到 dump 后怎么快速聚焦问题？
大促后时间紧迫，别从头加载整个 5GB hprof 文件。用 MAT（Eclipse Memory Analyzer）直奔关键入口：
- 打开后先点 “Leak Suspects Report”——它会自动标出占用 Retained Heap 最大的 1–3 个对象组，80% 的泄漏藏在这里
- 看 dominator tree，找
char[]、byte[]、HashMap$Node或业务类（如OrderCache、UserSession）的异常高占比 - 右键可疑对象 → “Path to GC Roots” → 勾选 “with all references”，重点看是否被静态集合、未清理的 ThreadLocal 或监听器强引用
进阶：让 dump 更“聪明”一点
光有 dump 还不够，要让它配合大促运维节奏：
- 加
-XX:OnOutOfMemoryError="sh /opt/app/bin/oom_alert.sh"，自动发企业微信告警+记录当前线程栈（jstack $PID > /tmp/oom_threads.log） - 在脚本里加磁盘水位检查，若剩余空间 < 5GB 则跳过 dump，优先保服务可用性
- 预发环境用相同参数压测，提前验证 dump 路径、大小、分析流程是否通路
