futuretask.get(timeout, unit)超时从调用时刻起算，非submit时刻；须捕获interruptedexception、executionexception、timeoutexception三类异常；单位需明确，超时后应调用cancel(true)主动终止任务。
Java中FutureTask的get(timeout, unit)是实现异步任务超时等待的正解，但用错就容易掉进线程阻塞、异常漏捕、超时失准等坑里。核心不是“能不能等”，而是“怎么等才安全可靠”。
超时起点不是提交时间，而是调用get的那一刻
很多人误以为超时计时从submit()开始——其实不是。get(long, TimeUnit)的超时窗口，是从你调用该方法的**那一瞬间**开始计算的。任务在队列里排队5秒、执行耗时8秒，你设了10秒超时，只要get()调用后10秒内没拿到结果，就会抛TimeoutException。它不管之前花了多少时间排队或初始化。
这意味着：
- 若下游服务响应波动大，需把P99延迟 ×1.5～2 作为超时基准，不能拍脑袋定100ms
- 线程池队列积压、GC停顿、CPU争抢都可能吃掉一部分超时余量，要预留缓冲
- 不要依赖isDone()轮询+sleep来“模拟”超时——精度差、浪费CPU、还可能刚完成就错过
必须捕获全部三种异常，缺一不可
get(timeout, unit)声明抛出InterruptedException、ExecutionException、TimeoutException。这三者语义完全不同，漏掉任何一个都会导致程序崩溃或逻辑断裂。
正确写法示例：
- TimeoutException：任务未完成，可降级返回默认值、触发重试、或调用future.cancel(true)主动终止
- ExecutionException：任务内部已失败，必须用e.getCause()取出原始异常（比如NullPointerException、SQLException），否则日志里只看到一层包装，无法定位根因
- InterruptedException：当前线程被中断，应立即恢复中断状态——Thread.currentThread().interrupt()，而不是忽略或吞掉
单位错误和硬编码是高频低级Bug
TimeUnit.SECONDS 和 TimeUnit.MILLISECONDS 差1000倍。写成get(5, TimeUnit.SECONDS)却本意是5毫秒，结果任务卡住5秒才超时，线上可能引发雪崩。
更稳妥的做法：
- 所有超时值从配置中心读取（如Nacos、Apollo），支持动态调整
- 不同依赖服务差异化配置：DB查询设200ms，HTTP调用设1500ms，缓存设50ms
- 在代码里显式写出单位含义，例如TIMEOUT_HTTP_MS = 1500，避免magic number
超时后任务未必停止，cancel(true)不是自动发生的
get()抛出TimeoutException，只代表“你等不及了”，不代表后台任务被终止。它可能还在运行、占着线程、消耗数据库连接或发着HTTP请求。
所以建议：
- 捕获TimeoutException后，立刻调用future.cancel(true)
- cancel(true)会尝试中断执行线程，但能否真正停住，取决于任务代码是否响应中断（比如在循环中检查Thread.interrupted()，或sleep/lock等可中断操作）
- 对不响应中断的老旧任务，考虑加层封装或改用带中断感知的IO库
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
