Java中手动throw new OutOfMemoryError()不会触发-XX:+CrashOnOutOfMemoryError，该参数仅响应JVM因真实内存耗尽（如堆、元空间分配失败）而自动抛出的OutOfMemoryError，属于JVM自救机制而非异常拦截器。
Java 中 throw new OutOfMemoryError() 不会触发 -XX:+CrashOnOutOfMemoryError，因为该 JVM 参数只对 JVM 自动抛出的 OutOfMemoryError（即堆/元空间等真实内存耗尽时由 JVM 内部触发）生效，不响应人工 throw 的异常。
CrashOnOutOfMemoryError 的实际作用范围
该参数仅在 JVM 检测到无法分配内存（如新生代 GC 后仍无法容纳对象、元空间扩容失败等）并自动构造和抛出 OutOfMemoryError 时，才会执行崩溃动作（如生成 core dump、退出进程）。它本质是“JVM 自救机制”，不是异常拦截器。
- JVM 自发抛出：触发
-XX:+CrashOnOutOfMemoryError→ 进程立即终止 - 代码手动 throw：仅是普通异常抛出，JVM 视为业务逻辑行为 → 不触发崩溃，除非上层未捕获导致线程终止（但 JVM 进程仍在）
想让容器因 OOM 立即退出，关键在触发真实内存耗尽
若目标是让容器快速失败（如配合 Kubernetes 的 liveness probe 或 restartPolicy），应避免模拟或手动抛异常，而是制造真实内存压力，让 JVM 自己走到崩溃临界点：
- 用
-Xmx256m限制堆大小，再持续分配大对象（如new byte[1024 * 1024]循环）直到撑爆堆 - 启用
-XX:+CrashOnOutOfMemoryError+-XX:ErrorFile=/dev/stderr（便于日志观察） - 可选加
-XX:+ExitOnOutOfMemoryError（更轻量，直接 exit，不生成 dump）
容器环境下的可靠组合建议
在 Docker/K8s 中确保容器真正退出，推荐以下 JVM 参数组合：
立即学习“Java免费学习笔记（深入）”；
-
-XX:+ExitOnOutOfMemoryError：比 Crash 更快，无 dump 开销，适合容器场景 -
-XX:+CrashOnOutOfMemoryError：需搭配-XX:NativeMemoryTracking=summary或监控工具确认是否真 OOM -
-XX:MaxMetaspaceSize=128m：防止元空间无限增长，加速元空间 OOM 触发 - 务必设置
-Xms和-Xmx相同，避免动态扩容掩盖问题
验证是否生效的小技巧
启动后检查 JVM 是否加载了对应标志：
- 运行
jps -l获取 PID，再执行jinfo -flag ExitOnOutOfMemoryError <pid>，输出-XX:+ExitOnOutOfMemoryError即表示已启用 - 故意触发 OOM（如用 Apache Commons 的
ObjectUtils.clone()递归复制大对象），观察进程是否秒退、容器是否重启 - 查看容器日志末尾是否有
java.lang.OutOfMemoryError: Java heap space及随后的Aborting due to java.lang.OutOfMemoryError
不复杂但容易忽略
