线程池默认静默吞掉任务异常，不打印日志也不传播；根本原因是FutureTask.run()将异常存入setException()而线程池不检查；重写afterExecute是唯一稳定捕获方式。
线程池任务抛异常却没打印日志？默认不处理 RuntimeException
Java 线程池（ThreadPoolExecutor）默认对任务中抛出的未捕获异常是“静默吞掉”的：既不打印堆栈，也不传播，更不会影响其他任务。这是很多人发现日志里完全看不到异常、排查卡住的根本原因。
根本原因是：任务实际由 FutureTask.run() 包装执行，其内部把异常吞进 setException()，而线程池本身不主动检查或输出这个异常。
常见错误现象：System.out.println("here"); 能打印，但后面抛了 NullPointerException 却毫无痕迹；监控发现任务“完成”了，实际中途失败。
- 别指望
try-catch写在提交的任务外层——那根本捕不到，因为任务是在另一个线程里跑的 -
execute(Runnable)提交的任务异常会被彻底忽略；submit(Callable)的异常会存到Future.get()，但没人调get()就等于没发生 - 哪怕你给线程池设置了
Thread.UncaughtExceptionHandler，对Runnable也无效——因为异常根本没“逃到”线程顶层
重写 afterExecute 是最直接可靠的钩子
afterExecute 是 ThreadPoolExecutor 提供的模板方法，在每个任务执行完（无论成功或异常）后被调用，且参数明确传入了异常对象（Throwable t），是唯一能稳定拿到原始异常的地方。
立即学习“Java免费学习笔记（深入）”；
注意：它只对 execute() 和 submit() 提交的 Runnable/Callable 生效，不适用于 ForkJoinPool 或第三方线程池。
实操建议：
- 继承
ThreadPoolExecutor，重写afterExecute，优先检查t != null，再打印或上报 - 不要在
afterExecute里做耗时操作（如远程日志），否则会阻塞线程池工作线程 - 如果任务是
Callable且正常返回，t为null；只有抛异常时才非空——这点和直觉一致，可放心判断
示例片段：
protected void afterExecute(Runnable r, Throwable t) {
if (t != null) {
log.error("Task execution failed", t);
}
}
ThreadFactory 设置 UncaughtExceptionHandler 只对部分场景有效
给线程池配的 ThreadFactory 可以设置每个线程的 UncaughtExceptionHandler，但它只捕获“线程顶层未捕获异常”，比如 run() 方法体外意外抛出的异常，或者 Thread.currentThread().stop() 这类已废弃操作引发的。
对绝大多数业务任务来说，异常都发生在 Runnable.run() 或 Callable.call() 内部，而这些方法本身没有 throws 声明，JVM 不认为它们是“线程顶层异常”，所以 UncaughtExceptionHandler 根本不会触发。
使用场景有限：
- 你自己在线程池外手动
new Thread(...).start()，且没包try-catch - 任务里显式调用了
Thread.currentThread().interrupt()后又误用了可能抛InterruptedException的阻塞方法，且没处理 - 极少数 native 层崩溃导致 JVM 抛出
InternalError等底层异常
换句话说：别依赖它来兜底业务逻辑异常。
Spring 中用 @Async 怎么办？别绕开 afterExecute
Spring 的 @Async 底层默认用的就是 ThreadPoolTaskExecutor（继承自 ThreadPoolExecutor），所以重写 afterExecute 依然生效。
但容易踩的坑是：有人试图用 @ExceptionHandler 或 AOP 拦截 @Async 方法——没用，因为异步调用不走 Spring MVC 的异常处理链，AOP 代理也通常只作用于同步调用入口。
正确做法：
- 自定义一个
ThreadPoolTaskExecutorBean，重写afterExecute - 确保该 Bean 被
@EnableAsync正确引用（通过AsyncConfigurer或@Bean(name = "taskExecutor")） - 避免在
afterExecute里调用 Spring 上下文中的 bean（比如applicationContext.getBean(XXX.class)），容易引发循环依赖或上下文未就绪问题
复杂点在于：如果你用的是 CompletableFuture 链式调用（如 supplyAsync(...).thenApply(...)），异常可能落在某个 stage 里，这时 afterExecute 仍能捕获，但堆栈可能被 CompletionException 包裹一层——记得用 t.getCause() 解包。
