不会。catch(exception e)完全捕获不到outofmemoryerror，因二者同为throwable直接子类，属平行继承关系；oom是jvm资源枯竭的不可恢复错误，不应被业务代码捕获处理。

不会。 catch(Exception e) 完全捕获不到 OutOfMemoryError（OOM）。

Exception 和 Error 是两条平行的继承线

Java 的异常体系以 Throwable 为根，其下直接分为两个分支：

• Exception：表示程序可预期、可恢复的异常（如 IOException、SQLException），部分需强制处理（checked），部分可不处理（unchecked，如 NullPointerException）
• Error：表示 JVM 级别的严重问题（如 OutOfMemoryError、StackOverflowError、NoClassDefFoundError），不属于应用逻辑范畴，设计上就不该被业务代码捕获

因为 OutOfMemoryError 是 Error 的子类，和 Exception 毫无继承关系，所以 catch(Exception e) 对它完全“视而不见”。

为什么有人觉得“好像捕获到了”？

常见误解来源有两类：

Java Maven Code Review

审查Java Maven项目（ZIP压缩包或GitLab仓库URL），检查代码规范、命名、模块边界、可维护性问题以及重复代码。

下载

• 误用了 catch(Throwable t) —— 这确实能捕获 OOM，但属于危险操作，不是推荐做法
• 在多线程场景中混淆了线程行为：某个线程因 OOM 崩溃退出，主线程或其他线程仍在运行，造成“服务没挂”的错觉；实际上出问题的线程已终止，状态可能已损坏

如果真想拦截 OOM，语法上可行吗？

语法上可以写 catch(OutOfMemoryError e)，JVM 不报错，但语义上错误、工程上危险：

• JVM 已处于内存枯竭状态，连日志输出、对象创建、字符串拼接等基础操作都可能再次触发 OOM
• 继续执行业务逻辑极易导致数据不一致、静默失败、线程死锁
• 掩盖真实故障，延误定位，干扰监控告警机制

正确响应方式是：配置 -XX:+HeapDumpOnOutOfMemoryError 自动保留现场，通过监控发现趋势，靠压测、调优、流式处理、杜绝内存泄漏来预防。

那 catch(Exception e) 的风险在哪？

它虽抓不到 OOM，但会吞掉本不该被掩盖的异常：

• NullPointerException、IllegalArgumentException 等 RuntimeException 子类——它们是代码缺陷信号，应修复而非捕获
• 本该向上抛出的受检异常（如 IOException），被统一吃掉后，调用方无法感知失败，逻辑可能跳过关键步骤
• 异常堆栈和原始 cause 链容易丢失，增加排查难度

真正该做的是：只捕获明确知道如何处理的具体异常类型，比如调用 HTTP 接口时捕获 TimeoutException 或 IOException；把兜底逻辑留给最外层统一处理机制（如 Spring 的 @ControllerAdvice）。

Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南