UncaughtExceptionHandler仅捕获未被捕获的运行时异常（如NullPointerException），不处理Checked异常、主线程异常、Thread.stop()或已try-catch的异常；需在start()前设置，线程池中需重写afterExecute()或统一try-catch。
UncaughtExceptionHandler 能捕获哪些异常
它只管「未被捕获的运行时异常」，也就是线程执行中突然炸了、没人 try-catch 的那种。比如 NullPointerException、ArrayIndexOutOfBoundsException，或者手动 throw 的 RuntimeException 子类。Checked 异常（如 IOException）不会触发它——因为编译器强制你处理，根本传不到这里。
常见错误现象：开了个新线程，里头出了 NullPointerException，控制台直接打印堆栈然后线程静默退出，主流程毫无感知。这就是没设 UncaughtExceptionHandler 的典型表现。
- 它不处理主线程的未捕获异常（主线程默认有 JVM 自带 handler，但子线程没有）
- 它不拦截
Thread.stop()这种已废弃的暴力终止（现在基本不用） - 如果线程 run() 里自己 try-catch 了所有异常，handler 根本不会被调用
怎么给单个线程设置 handler
最直接的方式是在启动前用 setUncaughtExceptionHandler() 指定。注意：必须在 start() 之前调，之后设无效。
Thread t = new Thread(() -> {
throw new RuntimeException("boom");
});
t.setUncaughtExceptionHandler((thread, ex) -> {
System.err.println("线程 " + thread.getName() + " 炸了：" + ex.getMessage());
});
t.start();
- lambda 参数
thread是出问题的线程对象，可用来区分日志来源 - handler 执行在「抛异常的线程」上下文中，不是主线程，别在里面做阻塞操作（如写文件、发 HTTP）
- 如果线程是通过线程池创建的，单独 set 不生效——线程池会复用线程，且通常覆盖掉你的 handler
如何让所有线程共享一个全局 handler
用 Thread.setDefaultUncaughtExceptionHandler()，它对后续新建的线程生效（不追溯已存在的线程）。适合统一日志、告警或资源清理。
立即学习“Java免费学习笔记（深入）”；
Thread.setDefaultUncaughtExceptionHandler((thread, ex) -> {
// 记录到 ELK 或发送企业微信告警
log.error("全局未捕获异常", ex);
});
- 它只影响「未显式设置 handler」的新线程；显式调用
setUncaughtExceptionHandler()的线程会优先用自己的 - Spring Boot 应用中，这个调用建议放在
@PostConstruct方法或 ApplicationRunner 里，确保早于业务线程启动 - Web 容器（如 Tomcat）可能有自己的线程模型，部分工作线程不受此影响，需结合容器文档确认
线程池场景下 handler 为什么经常失效
因为 ThreadPoolExecutor 默认把任务包装成 FutureTask，异常被吞进 get()，不会冒到线程层面。所以即使你设置了全局 handler，线程池里的异常也捕获不到。
- 正确做法是重写
afterExecute()：继承ThreadPoolExecutor，在该方法里检查Runnable是否为Future，然后调future.get()主动取异常 - 或者改用
Executors.newCachedThreadPool(runnable -> { ... })工厂方式，在线程工厂里给每个线程设 handler（但仅对未被 Future 包装的任务有效） - 更稳妥的是：所有提交到线程池的
Runnable都自己包一层 try-catch，把异常转成日志或回调
真正容易被忽略的点是：handler 只是“看到”异常，不代表它能阻止线程死亡——线程一旦抛出未捕获异常，必然终止。你要做的不是救活它，而是确保异常不被吞、不被漏、能定位、能响应。
