Java线程池不捕获传播任务异常，需三层兜底：任务内try-catch（Runnable需包裹run()，Callable需调用future.get()）、设置UncaughtExceptionHandler（处理未捕获RuntimeException/Error）、重写afterExecute统一记录日志与补偿。
Java 线程池本身不捕获也不传播任务异常，一旦任务抛出未处理的异常（尤其是 Runnable 的 run() 方法），该异常会直接终止当前工作线程——线程池虽会新建线程补位，但原始异常信息彻底丢失。因此，异常处理必须主动设计，不能依赖“默认行为”。核心思路是三层覆盖：任务内兜底、线程级兜底、执行后统一检查。
任务内部显式捕获（最基础也最关键）
这是第一道防线，也是最可控的方式。
- 对
Runnable：必须在run()方法里用try-catch包裹全部逻辑，否则任何未捕获异常都会导致线程退出且无日志。 - 对
Callable：call()可抛异常，但异常会被封装进Future；若不调用future.get()，异常永远不会暴露。
建议写法：
- 记录完整堆栈（
log.error("task failed", e)） - 避免裸 throw
RuntimeException（没日志、没上下文、无法定位） - 若需重试或补偿，应在 catch 块中明确触发（如发消息、写 DB），而非简单吞掉
设置 UncaughtExceptionHandler（线程级兜底）
适用于漏掉的 RuntimeException 或 Error，比如 NullPointerException、OutOfMemoryError 等。
它只对未被任务自身捕获的异常生效，且不能阻止线程终止（线程池会重建线程）。
实现方式：
Java Maven Common
下载
Java Maven 项目审查工作流的通用输入处理。当 Java Maven 项目以 ZIP压缩包或 GitLab 仓库 URL 形式提供且需要...时使用。
立即学习“Java免费学习笔记（深入）”；
- 自定义
ThreadFactory，在newThread()中为每个线程设置处理器 - 处理器中可记录日志、触发告警（如钉钉/企业微信）、上报监控系统
注意：Callable 的异常不会触发该处理器，因为已被 Future 捕获并封装。
重写 afterExecute 方法（统一后置检查）
ThreadPoolExecutor.afterExecute(Runnable r, Throwable t) 是官方提供的钩子，t 参数即任务执行中抛出的异常（包括 Runnable 未捕获的、以及 Future.get() 抛出的）。
这是集中做日志、熔断、指标统计、自动补偿的理想位置。
典型用法：
- 判断
t != null，说明任务执行失败 - 提取任务类型（如强转为业务 task）获取订单号、用户 ID 等关键字段，增强日志可追溯性
- 上报 Prometheus 指标（如
task_failure_total{pool="order",type="timeout"}） - 触发轻量级降级动作（如写入本地失败队列、发 Kafka 事件）
拒绝策略中的异常关联处理（任务过载时的补充）
当线程池饱和（max 线程数 + 队列满）时，新任务被拒绝，此时 RejectedExecutionHandler.rejectedExecution() 被调用。
虽然这不是“执行异常”，但它是任务生命周期中另一类关键失败场景，常需联动处理：
- 记录被拒任务的业务属性（如订单 ID、请求时间）而非仅
r.toString() - 同步落库或缓存，供人工核查或补偿调度
- 异步转发至消息队列，由下游消费者重试或降级
- 结合线程池状态（队列水位、活跃线程数）触发分级告警
不复杂但容易忽略。
