JVM堆转储不会自动规避连发风险，需组合-XX:HeapDumpPath、-XX:OnOutOfMemoryError及系统级ulimit与定时清理等防护措施，否则OOM反复触发将迅速耗尽磁盘空间。
不会自动规避。JVM 默认的堆转储（Heap Dump）触发机制（如 -XX:+HeapDumpOnOutOfMemoryError）在连续 OOM 时会反复生成 dump 文件，每个文件往往数百 MB 甚至数 GB，若无限制策略，几秒内即可耗尽磁盘空间——这是生产环境典型的“雪崩式磁盘打满”事故。
关键风险点：什么情况下 dump 会“连发不止”？
常见于以下场景：
- 内存泄漏未修复，应用持续分配对象 → 频繁触发 OOM → 每次都写一个 dump
- 堆大小设置不合理（如
-Xmx过高但容器内存受限），被 cgroup 杀掉前 JVM 自身先报 OOM 并 dump - 多个线程/请求并发触发 OOM（尤其在高并发服务中），dump 文件几乎同时落地
- 未配置 dump 路径或路径指向根分区（如
/tmp或/），缺乏隔离和容量控制
必须启用的三项 JVM 保护参数
仅加 -XX:+HeapDumpOnOutOfMemoryError 是危险操作。需组合使用以下参数形成闭环防护：
-
-XX:HeapDumpPath=/data/dumps/%p-%t.hprof：指定独立挂载的小容量磁盘目录（如专用于 dump 的/data/dumps），%p插入进程 PID，%t插入时间戳，避免覆盖，也便于定位 -
-XX:+HeapDumpBeforeFullGC（慎用）：仅在确认 Full GC 是 OOM 前兆时开启，配合 GC 日志分析使用；多数情况不建议启用，以防误触发 -
-XX:OnOutOfMemoryError="pkill -f 'java.*your-app.jar'; exit 1"：OOM 后立即终止 JVM 进程，阻止后续重复 dump；适用于可被编排系统（如 Kubernetes）自动拉起的场景
操作系统层兜底：用 ulimit + 定时清理双保险
JVM 参数不能替代系统级约束：
- 启动前执行
ulimit -f 2097152（单位 KB，即限制单个进程最多写 2GB 文件），可硬性截断超大 dump 生成 - 部署
cron任务定期清理过期 dump：find /data/dumps -name "*.hprof" -mmin +60 -delete（删除 1 小时前的 dump） - 对 dump 目录挂载
noexec,nosuid,nodev选项，降低安全风险
更优解：用监控代替被动 dump
真正规避“撑爆”，核心是减少 dump 触发次数：
- 接入 Prometheus + JVM Exporter，监控
jvm_memory_used_bytes{area="heap"}和jvm_gc_collection_seconds_count，当堆使用率 >85% 且 Young GC 频次突增时，提前告警、限流或扩容 - 用
jstat -gc <pid> 1s实时观察 OU（老年代使用量）是否持续攀升，判断是否即将 OOM，而非等 crash 后才 dump - 线上禁用
-XX:+HeapDumpOnOutOfMemoryError，改为人工触发：jmap -dump:format=b,file=/tmp/heap.hprof <pid>，确保 dump 在可控时机、可控位置执行
