默认情况下ThreadPoolExecutor执行Runnable抛未捕获异常会静默丢弃；应继承并重写afterExecute方法统一捕获记录，这是最稳妥精准的解决方案。
线程池里 Runnable 抛异常根本看不到日志？
默认情况下，ThreadPoolExecutor 执行的 Runnable 如果抛出未捕获异常，**JVM 不会打印堆栈，也不会传播到调用方**——它只是被 ThreadGroup.uncaughtException() 吞掉，而默认实现是静默丢弃。你看到的只有任务“没了”，没报错、没日志、没线索。
根本原因：线程池复用线程，每个任务在独立的执行上下文中运行，execute(Runnable) 不声明抛出异常，也不做包装处理。
- 用
submit(Callable)可以捕获异常，但得主动调用get()，不适合纯异步场景 -
execute(Runnable)最常用，也最容易漏掉异常 - 别指望
try-catch包住execute()调用本身——那 catch 不到任务内部的异常
重写 afterExecute() 是最稳妥的拦截点
继承 ThreadPoolExecutor，覆盖 afterExecute(Runnable, Throwable) 方法，在这里统一处理任务执行后的异常。这是 JDK 官方预留的钩子，比全局 UncaughtExceptionHandler 更精准（后者只能捕获线程崩溃级错误，对 Runnable 内部异常无效）。
public class LoggingThreadPoolExecutor extends ThreadPoolExecutor {
public LoggingThreadPoolExecutor(int corePoolSize, int maxPoolSize,
long keepAliveTime, TimeUnit unit,
BlockingQueue<Runnable> workQueue) {
super(corePoolSize, maxPoolSize, keepAliveTime, unit, workQueue);
}
@Override
protected void afterExecute(Runnable r, Throwable t) {
super.afterExecute(r, t);
if (t != null) {
// 这里能拿到任务执行时抛出的任何未捕获异常
log.error("Task execution failed", t);
}
}
}
-
t为非null表示任务执行中抛了未捕获异常；r是原始任务对象，可用于打日志标识 - 务必调用
super.afterExecute()，否则可能影响父类统计逻辑（如terminated()状态） - 避免在
afterExecute中做耗时操作（如远程写日志），否则阻塞线程池工作线程
Future.get() 只对 Callable 有效，且必须显式调用
如果你改用 submit(Callable<T>) 提交任务，异常会被封装进 ExecutionException，但**不调用 get() 就永远拿不到**——它不会自动抛、不会自动记录。
立即学习“Java免费学习笔记（深入）”；
-
Future.get()是阻塞的，适合需要结果或强错误反馈的场景（如批处理关键步骤） - 若只想要异常记录，又不想阻塞，可另起线程调用
get()并捕获ExecutionException -
Runnable提交后无法转成Future拿异常，别试图强转或反射绕过
别依赖 Thread.setDefaultUncaughtExceptionHandler()
这个设置只对「线程因未捕获异常而即将终止」生效，而线程池里的工作线程通常不会因为单个任务异常就退出——它们会吃掉异常、继续取下一个任务。所以绝大多数时候，这个 handler 根本不会触发。
- 它适合监控线程自身崩溃（比如线程 run() 方法顶层抛错），不是用来抓业务任务异常的
- 如果你看到它生效了，大概率说明线程池配置有严重问题（如核心线程数=0，或线程被意外中断后无法恢复）
- 和
afterExecute混用可能造成重复日志，建议只保留前者
真正要命的是：很多团队在线上只配置了 execute(Runnable) + 默认线程池，出了问题连哪条数据触发的异常都查不到。加一层 afterExecute 成本极低，却是定位线程池内异常的底线手段。
