futuretask.get()阻塞是因等待结果就绪，通过aqs挂起线程而非轮询，安全可中断；常见卡死原因包括无超时、线程池配置不当、忽略中断及任务未完成；应优先用带超时的get、捕获三类异常、合理配置线程池并考虑异步替代方案。
FutureTask.get() 阻塞主线程，不是因为“它故意卡住你”，而是因为它必须等结果真正就绪才能返回——这个等待过程是轻量、高效且可中断的。关键在于理解它怎么等、为什么安全、以及不加防护时为何会出问题。
阻塞的本质：挂起而非轮询
调用 get() 时，FutureTask 会先检查内部 state 字段：
- 若 state 是 NORMAL 或 EXCEPTIONAL（任务已完成），直接返回结果或抛出 ExecutionException；
- 若 state 仍是 NEW 或 COMPLETING，当前线程（比如主线程）会被封装成 WaitNode，加入 AQS 等待队列，并立即调用 LockSupport.park() 挂起；
- 挂起后线程进入 WAITING 状态，不消耗 CPU，也不抢锁、不自旋；
- 当任务执行结束（run() 方法退出），FutureTask 调用 finishCompletion()，遍历等待队列，对每个节点执行 LockSupport.unpark() 唤醒。
主线程卡死的常见原因
看似“阻塞合理”，但实际开发中主线程常被永久卡住，多因以下情况：
- 未设超时：用无参 get()，而任务因异常、死锁、无限 sleep 或线程池拒绝导致永远不完成；
- 线程池配置不当：如核心线程数=1、队列满、拒绝策略为 DiscardPolicy，新任务被丢弃但 FutureTask 状态仍为 NEW，get() 一直等不到唤醒；
- 忽略中断响应：主线程被 interrupt 后，get() 抛 InterruptedException，但未恢复中断状态（Thread.currentThread().interrupt()），后续逻辑可能误判为“正常继续”；
- 任务本身未触发完成：比如 Callable 中抛了未捕获的 Error（如 OutOfMemoryError），或 run() 方法未正常退出。
安全等待的实践要点
避免阻塞失控，核心是“有退路、有兜底、有感知”：
- 始终优先使用 get(long timeout, TimeUnit unit)，例如最多等 3 秒；
- 捕获并区分三种异常：TimeoutException（超时降级）、ExecutionException（查 cause 排查业务异常）、InterruptedException（恢复中断并退出）；
- 超时后，可主动调用 future.cancel(true) 尝试中断后台线程（仅对支持中断的操作有效，如 sleep、wait、BlockingQueue.take）；
- 确保线程池本身有合理配置：拒绝策略建议用 AbortPolicy 或自定义日志+告警，避免静默丢任务；
- 必要时用 isDone() 或 isCancelled() 做前置判断，避免盲目调用 get()。
替代思路：避免阻塞主线程
如果业务允许异步响应，可绕过 get() 阻塞：
- 用 CompletableFuture 配合 thenApply / whenComplete 实现非阻塞链式处理；
- 将 Future 提交到另一个专用回调线程池，完成后再通知主线程（如通过 Handler、EventBus 或 BlockingQueue）；
- 在 Web 场景中，结合 Spring 的 @Async 或 WebFlux 的 Mono/Flux 实现真正的响应式等待。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
