线程池任务抛出未捕获异常时会静默终止，需在ThreadFactory创建线程阶段设置UncaughtExceptionHandler；但该机制无法捕获吞异常、Future.get()和拒绝策略异常，应结合Callable+Future显式处理及日志监控增强可观测性。
线程池中任务抛出未捕获异常时，默认不会打印堆栈，也不会被主线程感知，线程会静默终止，导致任务丢失、监控失效、问题难以复现。使用 Thread.setUncaughtExceptionHandler 是补救的关键一环，但需注意它只对「当前线程」生效，而线程池中的工作线程是复用的——所以不能在提交任务时临时设置，而应在**线程创建阶段**就绑定异常处理器。
为线程池的每个工作线程统一设置异常处理器
标准线程池（如 ThreadPoolExecutor）通过 ThreadFactory 创建线程。你需要自定义 ThreadFactory，在每次新建线程时调用 setUncaughtExceptionHandler：
- 实现
ThreadFactory接口，或使用Executors.defaultThreadFactory()包装增强 - 在
newThread(Runnable r)中创建线程后，立即设置处理器 - 确保处理器逻辑能记录完整异常信息（包括线程名、时间、堆栈、任务上下文等）
ThreadFactory factory = r -> {
Thread t = Executors.defaultThreadFactory().newThread(r);
t.setUncaughtExceptionHandler((thread, ex) -> {
log.error("Uncaught exception in thread [{}], task: {}",
thread.getName(), r.getClass().getSimpleName(), ex);
});
return t;
};
ExecutorService pool = new ThreadPoolExecutor(2, 4, 60, TimeUnit.SECONDS,
new LinkedBlockingQueue(), factory);
避免仅依赖 UncaughtExceptionHandler 的盲区
该机制无法捕获以下情况，需额外防护：
-
Runnable.run() 内吞掉异常（例如空的
catch (Exception e) {}），此时异常根本不会上抛到线程层面 - Future.get() 抛出的 ExecutionException，属于调用方责任，需显式处理
-
线程池拒绝策略触发的异常（如
AbortPolicy抛出RejectedExecutionException），发生在提交阶段，与工作线程无关
建议在业务 Runnable 或 Callable 内部做最小兜底：至少记录异常，不静默吞掉。
结合日志与监控提升问题定位效率
单纯记录异常还不够，要让信息可追溯：
- 在异常日志中附加线程池名称、任务 ID（如有）、关键业务参数（脱敏后）
- 将异常类型、频次上报至监控系统（如 Prometheus + Grafana），设置告警阈值
- 考虑用 MDC（Mapped Diagnostic Context）在线程执行前注入上下文，使整条日志链路可关联
替代方案：优先用 Callable + Future 显式处理异常
相比 Runnable，Callable 的优势在于异常会封装进 Future.get()，调用方必须面对：
- 提交
Callable后，务必调用future.get()（或带超时的版本） - 捕获
ExecutionException，再通过.getCause()取出原始异常 - 适合对可靠性要求高、需强反馈的任务场景
这种方式比依赖线程级异常处理器更主动、更可控，应作为首选防御手段。
