isDone()仅是任务结束状态的快照，不阻塞也不支持超时；真正实现带超时等待必须使用get(timeout, unit)，它会阻塞并抛出TimeoutException、InterruptedException或ExecutionException。
isDone() 只是状态快照，不能替代超时等待逻辑
isDone() 返回 true 仅表示任务已结束（无论成功、异常或取消），但它不阻塞、不等待、不感知超时。常见误用是轮询 isDone() 加 Thread.sleep() 模拟超时——这既浪费 CPU，又无法精确控制耗时，还可能错过刚完成的任务。
真正需要的是「等待结果，但最多等 X 时间」，这必须交给 get(long, TimeUnit) 完成。它的语义是：若任务未完成，则当前线程阻塞；若超时仍未完成，则抛出 TimeoutException。
- 轮询
isDone()+sleep是反模式，精度差且不可靠 -
isDone()合理用途：在非阻塞路径中快速判断（如日志记录、状态上报） - 超时控制的唯一正解是
get(timeout, unit)，不是组合其他方法
get(timeout) 抛出的异常类型必须全部捕获
get(long, TimeUnit) 可能抛出三种受检异常：InterruptedException、ExecutionException、TimeoutException。漏捕获任一类型都会导致编译失败或运行时崩溃。
其中 ExecutionException 的 getCause() 才是原始异常（比如 NullPointerException 或自定义业务异常），直接打印 ExecutionException 本身毫无调试价值。
- 必须用
try-catch覆盖全部三种异常 -
TimeoutException表示任务未完成，此时可做降级或重试 -
ExecutionException需调用.getCause()获取真实异常，再分类处理 -
InterruptedException应恢复中断状态：Thread.currentThread().interrupt()
超时时间设置过短会导致大量假性超时
网络抖动、GC 暂停、线程调度延迟都可能让本应快速返回的任务“卡”住几十毫秒。若超时设为 100 ms，而平均响应是 80 ms、P99 是 220 ms，那么约 10% 的请求会无谓失败。
真实场景中，超时值应基于历史 P95/P99 延迟，并预留缓冲（通常 ×1.5～2）。同时注意：超时单位必须与传入的 TimeUnit 严格匹配——写 get(500, TimeUnit.MILLISECONDS) 和 get(500, TimeUnit.SECONDS) 效果天壤之别。
- 避免硬编码超时数值，建议从配置中心读取
- 对不同下游服务使用差异化超时（DB 查询 vs HTTP 调用）
- 单位错误是高频低级 Bug，务必核对
TimeUnit枚举值
cancel(true) 与 get(timeout) 共用时需注意中断传播时机
当 get(timeout) 抛出 TimeoutException 后，任务未必真正终止。若后续仍需主动终止，应调用 future.cancel(true)。但 cancel(true) 是否生效，取决于任务内部是否响应中断（比如是否在 while(!Thread.interrupted()) 中轮询）。
尤其要注意：如果任务已进入不可中断的阻塞操作（如 SocketInputStream.read()），cancel(true) 无法唤醒它，只能等待其自然结束或超时。此时 isDone() 仍为 false，直到阻塞返回。
-
TimeoutException不等于任务被取消，只是等待失败 -
cancel(true)是尽力而为，不能假设调用后任务立刻停止 - 关键资源（如数据库连接、HTTP 连接）需在任务内部配合
try-with-resources或显式 close，避免 cancel 后泄漏
get(timeout) 提供了标准契约，但它的可靠性完全依赖任务实现是否尊重中断——这点最容易被忽略。 
