Java全局异常处理器为什么不能只靠try-catch
因为try-catch只能捕获当前线程、显式调用路径上的异常，对异步线程、定时任务、Servlet容器启动失败、JVM底层错误完全无效。真正兜底的是Thread.setDefaultUncaughtExceptionHandler，它在任何线程抛出未捕获异常时触发，是最后的防线。
- Spring的
@ControllerAdvice和@ExceptionHandler只管Web层HTTP请求，对CompletableFuture线程池里的异常、@Scheduled任务崩溃、main线程启动失败全部失效 -
Thread.setDefaultUncaughtExceptionHandler必须在JVM启动早期注册，比如main方法第一行，否则主线程已启动的子线程可能错过设置 - 它不处理
Error子类（如OutOfMemoryError），这类问题通常应由JVM参数或监控系统介入，而非Java代码兜底
如何正确注册全局未捕获异常处理器
直接调用Thread.setDefaultUncaughtExceptionHandler即可，但要注意作用域和线程继承关系。主线程设置后，新创建的普通线程会自动继承该处理器；但线程池（如ThreadPoolExecutor）默认不继承，需手动配置。
- 在main方法开头注册最稳妥：
Thread.setDefaultUncaughtExceptionHandler((t, e) -> { System.err.println("Uncaught in thread [" + t.getName() + "]: " + e); // 记日志、上报、触发告警等 }); - 使用
Executors.defaultThreadFactory()创建的线程池不会自动应用该处理器，必须用自定义ThreadFactory显式设置：new ThreadPoolExecutor(1, 1, 0L, TimeUnit.SECONDS, new LinkedBlockingQueue<>(), r -> { Thread t = new Thread(r); t.setUncaughtExceptionHandler( Thread.getDefaultUncaughtExceptionHandler() ); return t; }); - Tomcat等容器启动后，部分线程（如acceptor、poller）由容器自己管理，它们不受JVM默认处理器影响，需配合容器特定机制（如Tomcat的
ErrorReportValve）
Spring Boot里要不要用@ExceptionHandler代替全局处理器
不要混淆职责。@ExceptionHandler是Web MVC的请求级异常翻译器，它把异常转成HTTP响应（如400/500），而Thread.setDefaultUncaughtExceptionHandler是JVM级保底，处理那些根本没走到Web层的崩溃。
当用户要求为 Java 代码添加注释、修改注释、审查注释、整理注释格式，或要求按照代码注释规范处理 Java 文件时，使用本技能。本技能用于统一生成和维护 Java 类注释模板、按 Git 对比 release 判断版本号、补充每行代码上方中文块注释、调整注释空行规则，并保持 Java 文件 UTF-8 无 BOM 编码。典型触发场景包括：补充类注释、更新 @version、检查 @author 来源、整理行尾注释、把注释放到代码上一行、检查注释是否符合规范、构建前检查 Java 注释风格。
- 如果只配了
@ControllerAdvice，后台定时任务抛NullPointerException会直接静默退出，连日志都不打 - Spring Boot 2.5+提供了
SpringApplication.setUncaughtExceptionHandler，但它本质只是包装了Thread.setDefaultUncaughtExceptionHandler，且仅对Spring管理的主线程有效，不改变底层行为 - 两者应该共存：Web异常走
@ExceptionHandler友好返回，系统级异常走Thread.setDefaultUncaughtExceptionHandler确保可观测
容易被忽略的兼容性与日志陷阱
很多团队以为加了全局处理器就万事大吉，结果线上OOM或死锁时日志全丢——问题常出在日志框架本身依赖线程上下文，而异常处理器运行在线程崩溃瞬间，SLF4J的MDC、Logback的AsyncAppender都可能失效或阻塞。
立即学习“Java免费学习笔记（深入）”；
- 避免在处理器里调用复杂日志方法（如带MDC、异步写入、网络上报），优先用
System.err.println或同步文件写入 - 不要在处理器中抛出新异常，会导致JVM直接终止线程且无提示
- Android或某些嵌入式JVM（如J9精简版）可能不支持
setDefaultUncaughtExceptionHandler，需提前验证Thread.class.getDeclaredMethod("setDefaultUncaughtExceptionHandler", ...)
真正的兜底不是“写个handler就完事”，而是确认它在所有线程类型、所有部署环境、所有异常层级下确实能执行到——这需要实测，而不是相信文档。
