futuretask 不处理异常，仅存储异常并在 get() 时封装为 executionexception 抛出；需用 callable 而非 runnable，避免空 catch，分类型捕获 timeoutexception、executionexception（需 getcause()）、interruptedexception（恢复中断状态），结合超时与状态检查，主动取消并记录可观测信息。
FutureTask 本身不处理异常，它只是把任务执行中抛出的异常“存起来”，等你调用 get() 时再统一包装成 ExecutionException 抛出。所谓“优雅处理”，核心是：不让异常漏掉、不掩盖原始原因、不阻塞主线程、不丢失业务上下文。
明确异常来源：Callable 才会暴露真实异常
只有提交 Callable 任务时，内部异常才能被 FutureTask 捕获并封装；若提交的是 Runnable，其 run() 方法不声明抛异常，内部异常会被线程默认异常处理器静默吞掉，get() 不会抛 ExecutionException，结果就“无声失败”了。
- 务必使用
Callable<t></t>而非Runnable，确保业务逻辑可抛受检/非受检异常 - 避免在
Callable.call()中空 catch 异常，否则原始错误信息彻底丢失
分类型捕获 get() 异常，不做笼统处理
直接写 catch (Exception e) 会混淆三类语义完全不同的异常，导致降级失效、中断被忽略、问题难以定位。
JavaStoryDevelop
下载
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
-
TimeoutException（仅出现在带超时的
get(long, TimeUnit)）：表示响应延迟超标，应立即走降级路径，比如返回缓存值、空对象或兜底文案 -
ExecutionException：包裹的是任务内真实异常，必须调用
e.getCause()获取原始异常，记录完整堆栈，便于排查是 SQL 错误、NPE 还是业务校验失败 -
InterruptedException：说明当前线程被外部中断，应立刻恢复中断状态
Thread.currentThread().interrupt()，让上层能感知并终止后续流程
结合超时与状态检查，避免无谓等待
不设超时的 get() 可能无限阻塞；盲目轮询 isDone() 又浪费 CPU。推荐组合策略：
- 始终优先使用
future.get(3, TimeUnit.SECONDS)，而非无参get() - 若超时后仍需尝试获取结果，可先用
isDone()判断是否已结束，再决定是否再次调用get()（不带超时） - 对关键任务，可在超时后加一次短时重试（如再等 500ms），但需控制总耗时，避免雪崩
主动取消 + 异常归因，提升可观测性
当任务明显无望完成（如用户已退出、接口已超时），应主动调用 cancel(true) 尝试中断，并在日志中标记“被取消”，而非等到 get() 抛 CancellationException 才发现。
- 取消后调用
get()会抛CancellationException，这不是任务内部异常，需单独捕获并区别对待 - 建议在日志中同时记录任务 ID、提交时间、取消原因、是否成功中断，方便链路追踪
- 若任务已进入
EXCEPTIONAL状态（即已抛异常），cancel()不生效，此时仍要靠get()拿到原始异常
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
