java中uncaughtexceptionhandler用于捕获未被try-catch处理的子线程异常，通过thread.setdefaultuncaughtexceptionhandler设置全局处理器（需在main开头调用），单线程可单独设置更高优先级的处理器，线程池推荐用自定义threadfactory注入handler，spring中应通过applicationrunner或asyncconfigurer集成。
Java 中的 UncaughtExceptionHandler 全局捕获机制，主要用于处理**未被 try-catch 捕获、且未被上层线程处理的异常**，尤其是子线程中抛出的运行时异常。它不能捕获主线程（main 线程）中未捕获的异常（主线程异常会直接终止 JVM），但对所有非守护线程（包括自定义线程、线程池中的工作线程等）非常关键。
设置默认全局异常处理器
通过 Thread.setDefaultUncaughtExceptionHandler() 可为 JVM 中所有未显式设置处理器的线程指定统一的兜底处理逻辑：
- 该设置需尽早调用（通常在 main 方法开头或应用初始化阶段），否则可能遗漏早期创建的线程
- 处理器仅对后续新创建的线程生效，已启动的线程不受影响
- 典型用法是记录异常堆栈、上报监控、清理资源，**不建议在此处尝试“恢复”执行流**
Thread.setDefaultUncaughtExceptionHandler((thread, throwable) -> {
System.err.println("Uncaught exception in thread " + thread.getName() + ": " + throwable);
// 记录到日志系统、发送告警、保存 dump 等
});
为单个线程单独配置处理器
若需对某一线程定制异常处理行为（例如关键后台任务需要特殊兜底），可调用 thread.setUncaughtExceptionHandler()：
- 优先级高于默认处理器：线程自身设置了处理器 → 使用自身；否则才回退到默认处理器
- 适用于有明确生命周期和语义的线程，如定时调度线程、消息监听线程等
- 注意：线程必须在
start()前设置，启动后设置无效
线程池场景下的注意事项
普通线程池（如 ThreadPoolExecutor）中的工作线程默认继承 JVM 默认处理器，但存在两个常见陷阱：
-
submit() 提交的 Callable/Runnable 被包装后异常可能被吞掉：使用
submit()时，异常会被封装进ExecutionException，需显式调用get()才暴露；此时UncaughtExceptionHandler不触发 -
execute() 提交的任务才会真正走未捕获异常路径：推荐对线程池使用
execute()+ 全局 handler 组合，或重写afterExecute()方法做统一异常捕获
更稳妥的做法是在线程池构造时传入自定义 ThreadFactory，在创建线程时统一设置 handler：
ThreadFactory factory = r -> {
Thread t = new Thread(r);
t.setUncaughtExceptionHandler(handler);
return t;
};
ExecutorService pool = new ThreadPoolExecutor(..., factory);
Spring 环境中的集成建议
在 Spring 应用中，不建议在 main 方法里硬编码设置全局 handler，而应借助框架生命周期管理：
- 实现
ApplicationRunner或CommandLineRunner，在容器启动完成后设置setDefaultUncaughtExceptionHandler - 对
@Async方法，其底层线程池需通过AsyncConfigurer自定义TaskExecutor，并在ThreadFactory中注入 handler - 避免与 Spring 的
@ControllerAdvice混淆：后者只处理 Web 层 MVC 异常，不覆盖线程级未捕获异常
