必须设超时、捕获三类异常、主动清理未完成任务：用future.get(3, TimeUnit.SECONDS)替代无参get()，超时值依场景配置，捕获InterruptedException、ExecutionException、TimeoutException并分别处理，超时后立即future.cancel(true)，警惕线程池配置导致的隐性卡死。
直接用 FutureTask.get() 不带参数，等于把线程交给命运——任务不结束，主线程就永远卡着。这不是“等待”，是停摆。避免假死，核心就三点：必须设超时、必须捕获三类异常、必须主动清理未完成任务。
一定要用带超时的 get 方法
无参 get() 没有退出机制，一旦任务因死锁、无限循环、资源争用或线程池拒绝而卡住，调用线程就会一直阻塞。哪怕只等 1 毫秒，也比无限等强。
- 写成
future.get(3, TimeUnit.SECONDS)，别写future.get() - 超时值不能拍脑袋定：HTTP 调用建议 1–2 秒，缓存操作控制在 50ms 内，DB 查询视复杂度设 200–500ms
- 所有超时数值建议从配置中心读取（如 Nacos），便于线上动态调整，避免改代码重启
必须捕获 InterruptedException、ExecutionException、TimeoutException
这三类异常语义完全不同，漏掉任何一个都可能让程序静默失败或状态错乱。
-
TimeoutException：任务没做完，但已超时。此时应立刻调用
future.cancel(true)中断执行线程，释放资源 -
ExecutionException：任务内部抛了异常（比如空指针、SQL 异常）。要用
e.getCause()取出原始异常，否则日志里只有包装层，无法定位真实问题 -
InterruptedException：当前线程被中断。不能吞掉，必须立即恢复中断状态：
Thread.currentThread().interrupt()
别让 cancel(true) 成为摆设
超时后只打印一句“超时了”却不取消任务，等于放任后台线程继续跑。它可能占用数据库连接、持有锁、持续消耗 CPU，甚至拖垮整个线程池。
立即学习“Java免费学习笔记（深入）”；
- 每次捕获
TimeoutException后，紧跟future.cancel(true) -
cancel(true)会尝试中断正在执行的线程，但前提是任务逻辑里响应了中断（比如在循环中检查Thread.interrupted()或调用可中断方法如sleep、wait、BlockingQueue.take()） - 如果任务本身不响应中断（例如纯计算、忙循环），
cancel(true)效果有限，需从任务设计层面规避
警惕线程池配置引发的隐性卡死
即使加了超时，线程池配错也会让 get() 看似“等不到结果”。常见陷阱：
- 单线程池 + 队列满 + 拒绝策略为
DiscardPolicy：任务被丢弃，但FutureTask状态仍是NEW，get()无限等待 - 核心线程数过小、队列无界、突发流量涌入：新任务排队太久，超时还没开始计就已注定失败
- 建议使用有界队列 +
CallerRunsPolicy，让调用方自己执行任务，避免积压和丢失
