Future.get() 阻塞是基于AQS的挂起唤醒机制，非busy-wait；通过LockSupport.park()使线程进入WAITING状态，不消耗CPU；支持中断和超时控制，多线程调用安全，但需防资源泄漏与级联故障。
Future.get() 会阻塞，是因为它内部采用“轮询+等待状态变更”的机制来同步获取异步任务结果，而不是主动轮询消耗CPU。本质是基于AQS（AbstractQueuedSynchronizer）实现的锁与条件队列协作，让调用线程挂起，直到任务完成并唤醒它。
Future.get 的阻塞不是简单 while(true) 循环
很多人误以为 get() 是靠 busy-wait（空转循环）检查任务状态，实际并非如此。以 FutureTask 为例，其内部继承自 AQS，用 state 字段表示任务状态（NEW、COMPLETING、NORMAL、EXCEPTIONAL、CANCELLED、INTERRUPTING、INTERRUPTED）。当任务未完成时，get() 调用 awaitDone() 方法，将当前线程封装为 Node 加入 AQS 的等待队列，并调用 LockSupport.park() 挂起线程——此时线程进入 WAITING 状态，不消耗 CPU 资源。
- 任务执行完毕（正常返回或抛异常）后，FutureTask 会调用 finishCompletion()，遍历等待队列，对每个节点调用 LockSupport.unpark() 唤醒
- 被唤醒的线程重新竞争 AQS 锁，检查 state 是否已更新，再决定是否返回结果或抛出 ExecutionException/InterruptedException
- 整个过程依赖 JVM 线程调度和底层操作系统线程阻塞原语（如 pthread_cond_wait），高效且轻量
中断响应与超时控制是阻塞的安全保障
阻塞不能无限期持续，Future.get() 提供了两种可控方式避免死等：
- 无参 get()：阻塞到任务完成，但可被中断。若线程在 park 中被 interrupt()，会立即抛出 InterruptedException，state 不变，调用方需自行处理中断信号
- 带超时的 get(long timeout, TimeUnit unit)：底层调用 LockSupport.parkNanos()，支持纳秒级精度超时；超时后自动返回，不抛异常，但需手动检查是否 done（isDone() == false 表示超时未完成）
- 注意：超时返回后，任务仍在后台运行，Future 本身不会取消它，除非显式调用 cancel(true)
并发环境下 get() 的线程安全关键点
多个线程同时调用同一个 Future 实例的 get() 是安全的，因为状态变更和等待逻辑都受 AQS 内置锁保护。但需注意以下边界情况：
立即学习“Java免费学习笔记（深入）”；
- 任务执行中被 cancel(true)，且 mayInterruptIfRunning = true，则可能触发正在运行的线程的 interrupt()，影响其内部逻辑（如 sleep、wait、BlockingQueue.take 等可中断操作）
- 任务抛出未捕获异常，ExecutionException 包装原始异常，在 get() 时统一抛出；异常只抛一次，后续 get() 仍抛同一 ExecutionException
- 若任务使用了共享资源（如静态变量、外部连接池），而 get() 阻塞时间过长，可能引发连接泄漏、线程饥饿等问题——这不是 Future 本身的缺陷，而是业务设计需配合超时与熔断
不推荐直接裸调 get() 的典型场景
在高吞吐或响应敏感系统中，盲目调用无超时的 get() 容易引发级联故障：
- 线程池中 worker 线程被阻塞，导致新任务排队甚至触发拒绝策略
- Web 请求线程（如 Tomcat 的 NIO worker）被卡住，QPS 下降、超时堆积
- 分布式调用链中，上游因下游 Future 无响应而整体 hang 住
- 正确做法是：始终设置合理超时 + 异常兜底 + 必要时 fallback（如 CompletableFuture.supplyAsync().orTimeout().handle()）
