Java全局异常处理配置全攻略

Java全局异常处理远不止于@ControllerAdvice或try-catch，真正的兜底防线是JVM级的Thread.setDefaultUncaughtExceptionHandler——它能在任意线程（包括异步任务、定时器、主线程）抛出未捕获异常时触发，但必须在启动早期注册、手动适配线程池、绕开容器私有线程，并警惕日志框架失效、OOM不捕获、Android兼容性等隐形陷阱；唯有将Web层异常翻译与JVM级崩溃观测分层协同、实测验证各场景覆盖，才能构建真正可靠的系统可观测性基石。

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层的崩溃。

• 如果只配了@ControllerAdvice，后台定时任务抛NullPointerException会直接静默退出，连日志都不打
• Spring Boot 2.5+提供了SpringApplication.setUncaughtExceptionHandler，但它本质只是包装了Thread.setDefaultUncaughtExceptionHandler，且仅对Spring管理的主线程有效，不改变底层行为
• 两者应该共存：Web异常走@ExceptionHandler友好返回，系统级异常走Thread.setDefaultUncaughtExceptionHandler确保可观测

容易被忽略的兼容性与日志陷阱

很多团队以为加了全局处理器就万事大吉，结果线上OOM或死锁时日志全丢——问题常出在日志框架本身依赖线程上下文，而异常处理器运行在线程崩溃瞬间，SLF4J的MDC、Logback的AsyncAppender都可能失效或阻塞。

• 避免在处理器里调用复杂日志方法（如带MDC、异步写入、网络上报），优先用System.err.println或同步文件写入
• 不要在处理器中抛出新异常，会导致JVM直接终止线程且无提示
• Android或某些嵌入式JVM（如J9精简版）可能不支持setDefaultUncaughtExceptionHandler，需提前验证Thread.class.getDeclaredMethod("setDefaultUncaughtExceptionHandler", ...)

真正的兜底不是“写个handler就完事”，而是确认它在所有线程类型、所有部署环境、所有异常层级下确实能执行到——这需要实测，而不是相信文档。

以上就是《Java全局异常处理配置全攻略》的详细内容，更多关于的资料请关注golang学习网公众号！