Thread.setUncaughtExceptionHandler()只捕获指定线程run()中未被try-catch处理的Throwable（含Exception和Error），不捕获主线程异常、已处理异常及Future.get()抛出的ExecutionException。
Thread.setUncaughtExceptionHandler() 能捕获哪些异常
它只捕获子线程中 run() 方法内、未被 try-catch 捕获的 Throwable（包括 Error 和 Exception），但不捕获主线程的异常，也不捕获已显式处理过的异常。
常见误判场景：用 ExecutorService 提交 Runnable 时，若线程池内部复用线程，且未为每个任务单独设置 handler，就可能漏捕——因为 setUncaughtExceptionHandler() 是绑定到具体 Thread 实例的，不是全局静态开关。
- 只对调用该方法的线程实例生效，新建线程必须显式设置
- 如果线程执行完
run()后退出，handler 不会自动继承给下一次复用的线程 -
Future.get()抛出的ExecutionException属于主线程异常，不在该 handler 范围内
如何正确为自定义线程设置 handler
最直接的方式是在启动前调用 setUncaughtExceptionHandler()，确保 handler 在异常发生前已就位：
Thread thread = new Thread(() -> {
throw new RuntimeException("boom in child");
});
thread.setUncaughtExceptionHandler((t, e) -> {
System.err.println("Uncaught in " + t.getName() + ": " + e);
});
thread.start();
- 必须在
start()之前设置，否则无效（JVM 不保证之后生效） - handler 中避免阻塞或抛出新异常，否则 JVM 会退回到默认行为（打印堆栈并终止线程）
- 若需记录日志，建议用异步 logger（如 SLF4J + Logback 的 async appender），防止 handler 反而拖慢线程退出
使用 Thread.setDefaultUncaughtExceptionHandler() 的注意事项
这个静态方法设置的是“线程默认处理器”，仅对后续创建、且未显式设置 handler 的线程生效。它不能覆盖已设置的实例 handler，也不影响已启动的线程。
典型陷阱是误以为设一次就一劳永逸——其实 new Thread() 创建的每个线程都需单独继承该默认 handler，而线程池（如 ThreadPoolExecutor）通常会绕过它，除非你重写 newThread() 工厂方法。
- 推荐在 main 方法开头尽早设置：
Thread.setDefaultUncaughtExceptionHandler(...) - Spring 等框架管理的线程（如 @Async）往往使用自定义
ThreadFactory，需主动将默认 handler 传入工厂 - Android 中主线程的崩溃由系统接管，该方法对 UI 线程无效
线程池中如何稳定捕获异常
标准 ExecutorService 不会把任务异常透传给线程的 uncaught handler，因为任务实际运行在 runWorker() 内部，异常被吞掉后仅通过 afterExecute() 钩子暴露。所以不能只依赖 setUncaughtExceptionHandler()。
可靠做法是：继承 ThreadPoolExecutor，重写 afterExecute()，并在其中检查 Runnable 是否为 Future、是否已异常完成。
- 对于
submit(Runnable)，异常会包装进Future，必须调用get()才可见 - 对于
execute(Runnable)，可重写afterExecute()并判断thrown != null - 更稳妥的是统一用
submit(Callable)，强制异常走Future.get()流程，由调用方处理
真正容易被忽略的是：即使设置了 handler，线程池中的异常仍可能导致资源泄漏（比如连接未关闭、锁未释放），handler 只负责“看见”异常，不自动回滚或清理。
