java线程池任务异常默认静默丢失，正确处理需四层设计：1. 提交用callable+future显式捕获；2. 重写afterexecute统一监控；3. 自定义threadfactory设置uncaughtexceptionhandler兜底；4. 封装带退避策略的重试逻辑。
Java线程池中任务异常容易“静默丢失”，既难发现又难恢复。关键不是等异常发生再补救，而是从提交方式、执行兜底、异常捕获和重试策略四个层面主动设计。
用Callable+Future显式捕获任务异常
Runnable的run()方法不声明异常，一旦抛出就直接终止且无法向上反馈；Callable的call()方法可抛出异常，并通过Future.get()获取原始异常。这是最直接可控的捕获路径。
- 提交任务时统一用
executor.submit(Callable)，避免使用execute(Runnable) - 调用
future.get()必须包裹try-catch，ExecutionException.getCause()才是业务异常本身 - 若不需要阻塞等待结果，也可在异步回调中处理：用
CompletableFuture.supplyAsync(..., executor).handle((r, ex) -> { ... })
通过afterExecute统一监控未捕获异常
即使用了Callable，若忘记调用get()，或任务是用execute提交的Runnable，异常仍会掉入线程池默认处理逻辑——仅打印堆栈后吞掉。重写ThreadPoolExecutor.afterExecute能拦截所有执行结束后的异常。
JavaStoryDevelop
下载
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
- 继承ThreadPoolExecutor，覆盖
afterExecute(Runnable r, Throwable t) - 当
t != null时，说明任务执行中抛出了未捕获异常，可记录日志、上报监控、触发告警 - 注意：该方法也会在正常完成时被调用（此时t为null），需判空区分
设置UncaughtExceptionHandler防止线程退出失联
线程池中的工作线程若因未捕获异常而终止，线程池可能悄悄新建线程继续服务，但异常已丢失。通过ThreadFactory为每个线程设置UncaughtExceptionHandler，确保异常有出口。
- 自定义ThreadFactory，在创建Thread时调用
t.setUncaughtExceptionHandler(...) - 处理器内可做三件事：记录完整堆栈、发送至APM系统（如SkyWalking）、决定是否重启该线程（谨慎）
- 该机制是最后一道防线，对submit/execute提交的任务都生效
封装重试逻辑实现失败自动恢复
捕获异常只是第一步，真正提升可用性的是让任务具备自我修复能力。重试不能简单循环，需考虑次数、间隔与失败类型。
- 区分可重试异常（如网络超时、临时拒绝）和不可重试异常（如参数校验失败、空指针），后者重试无意义
- 采用指数退避：第1次延迟100ms，第2次200ms，第3次400ms，避免雪崩式重试
- 推荐封装通用重试模板，例如：
RetryExecutor.submit(() -> api.call(), 3, Duration.ofMillis(100)) - 生产环境建议引入Resilience4j或Spring Retry，支持熔断、降级等进阶能力
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
