不能直接捕获。Thread.UncaughtExceptionHandler仅对未被捕获且冒泡至线程run()顶层的异常生效，而线程池任务异常被封装在run()内部或Future中，不会触发该handler；需通过重写ThreadPoolExecutor.afterExecute()实现真正兜底。
Thread.UncaughtExceptionHandler 能捕获线程池里的异常吗？
不能直接捕获。线程池（如 ThreadPoolExecutor）复用线程，任务异常默认由 Future.get() 抛出或被 execute() 吞掉，UncaughtExceptionHandler 只对「未捕获且未被任何 try-catch 拦截的顶层异常」生效，而线程池中任务通常运行在 run() 内部，异常不会冒泡到线程的 run() 方法出口，因此 handler 不会被触发。
为什么 submit() + get() 不适合全局兜底？
它把异常控制权交还给调用方，无法做到“无感捕获+自动持久化”。常见误用是：只对 submit() 的 Future 做 get()，但一旦忘记调用、或任务被取消、或异步链路中断，异常就彻底丢失。更危险的是，在 Spring 等框架里，@Async 方法抛异常后若没显式处理，堆栈直接消失。
-
execute()提交的任务：异常被吞，UncaughtExceptionHandler无感知 -
submit()返回的Future：异常藏在get()中，不调用就不抛 - 线程池自定义
afterExecute()是唯一可靠入口，但需继承ThreadPoolExecutor
用 afterExecute() 替代 UncaughtExceptionHandler 实现真正兜底
重写 ThreadPoolExecutor.afterExecute() 是最稳妥的方式——它在每个任务执行结束后被调用，无论成功或抛异常，且参数明确提供 Runnable 和 Throwable。这是 JDK 官方预留的异常钩子，比依赖线程级 handler 更精准。
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 && r instanceof Future>) {
try {
// 检查 submit() 任务是否因异常终止但未 get()
Object result = ((Future>) r).get(0, TimeUnit.NANOSECONDS);
} catch (ExecutionException ex) {
t = ex.getCause();
} catch (TimeoutException | InterruptedException ignored) {}
}
if (t != null) {
logAndPersist(t); // 自定义持久化逻辑，如写入 ELK / 文件 / DB
}
}
private void logAndPersist(Throwable t) {
String stack = ExceptionUtils.getStackTrace(t); // Apache Commons Lang
// 写磁盘、发 MQ、存数据库等
}
}
</runnable>
容易忽略的关键细节
即使用了 afterExecute()，仍有三个坑常导致堆栈丢失：
- 未覆盖
beforeExecute()和afterExecute()配对使用时，若任务被拒绝（如RejectedExecutionHandler触发），afterExecute()不会调用 -
Future.get()若已调用并清除了异常状态，再次检查会返回null；必须在afterExecute()里第一时间判断t != null，再 fallback 到Future.get() - 日志异步写入时若用线程池自身记录异常，可能引发死锁或递归调用——持久化逻辑必须用独立线程或同步落盘
真正可靠的方案，永远是把异常捕获点压到离任务最近的位置，而不是指望线程退出前的最后机会。
