runtimeexception不会被jvm自动捕获，它属于非检查型异常，编译器不强制处理；未捕获时jvm仅终止线程并打印栈轨迹，真正捕获需开发者通过try-catch、@controlleradvice或thread.setdefaultuncaughtexceptionhandler等主动实现。
RuntimeException 不会被 JVM 自动捕获——它不会被强制要求 try-catch，也不会由 JVM 主动拦截并处理。JVM 只在未捕获时终止当前线程并打印异常栈，这是它的默认行为，不是“自动捕获”。
RuntimeException 的本质：无需声明，但不被 JVM 捕获
RuntimeException 是 unchecked exception（运行时异常），继承自 Exception 但绕过了编译期检查。Java 编译器不要求你显式处理它，但 JVM 本身从不主动捕获任何异常——无论 checked 还是 unchecked。一旦抛出且未被代码 catch，它就会沿调用栈向上冒泡，直到线程结束。
- JVM 不会为 RuntimeException 插入隐式 try-catch
- 没有全局“自动捕获机制”，除非你手动注册 UncaughtExceptionHandler
- main 线程中未捕获的 RuntimeException 会导致程序退出，并输出 stack trace 到 stderr
如何让未捕获的 RuntimeException “被处理”
所谓“捕获”，实际依赖开发者主动介入。常见方式包括：
- 在关键入口处加 try-catch：比如 main 方法、Servlet 的 service()、Spring Controller 方法
-
设置线程默认异常处理器：
Thread.setDefaultUncaughtExceptionHandler(...)，对所有未捕获异常生效（含 RuntimeException） - 框架级兜底：Spring 用 @ControllerAdvice + @ExceptionHandler；Web 容器可通过 error-page 配置错误页面
- JVM 参数配合日志工具：虽然不能捕获，但可结合 -XX:+PrintGCExceptionDetails 或 APM 工具（如 SkyWalking）做异常监控和告警
为什么容易误解“JVM 自动捕获”
常见混淆点来自现象误读：
- 看到控制台打印红色 stack trace，误以为 JVM “捕获并输出”——其实是异常终止线程后，JVM 将异常信息写入 System.err
- IDE 运行时弹窗或高亮，是开发工具做的增强提示，非 JVM 行为
- 某些容器（如 Tomcat）会捕获 Servlet 中的异常并返回 500 页面，这是容器逻辑，不是 JVM 本职
实用建议：别等崩溃，主动防御
RuntimeException 多源于编程疏漏（空指针、数组越界、类型转换失败等）。与其依赖“捕获”，不如：
- 用 Optional、Objects.requireNonNull、Collection.isEmpty() 等提前规避
- 单元测试覆盖边界场景，让 RuntimeException 在测试阶段暴露
- 生产环境开启严格日志（如 logback 的 ERROR 级别 + 异常堆栈），配合监控告警
- 对第三方 API 调用做 try-catch 包装，转为业务可识别的错误码或状态
不复杂但容易忽略：JVM 从不替你 catch RuntimeException，它只负责让程序按规则停下来。真正的“捕获”，永远始于你的代码。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
