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能拦截所有执行结束后的异常。
- 继承ThreadPoolExecutor，覆盖
afterExecute(Runnable r, Throwable t) - 当
t != null时，说明任务执行中抛出了未捕获异常，可记录日志、上报监控、触发告警 - 注意：该方法也会在正常完成时被调用（此时t为null），需判空区分
设置UncaughtExceptionHandler防止线程退出失联
线程池中的工作线程若因未捕获异常而终止，线程池可能悄悄新建线程继续服务，但异常已丢失。通过ThreadFactory为每个线程设置UncaughtExceptionHandler，确保异常有出口。
立即学习“Java免费学习笔记（深入）”；
- 自定义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，支持熔断、降级等进阶能力
