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 等。
它只对未被任务自身捕获的异常生效，且不能阻止线程终止（线程池会重建线程）。
实现方式：
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
- 自定义
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() - 同步落库或缓存，供人工核查或补偿调度
- 异步转发至消息队列，由下游消费者重试或降级
- 结合线程池状态（队列水位、活跃线程数）触发分级告警
不复杂但容易忽略。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
