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() 提供了两种可控方式避免死等：

java-api-doc-generator

分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。

下载

• 无参 get()：阻塞到任务完成，但可被中断。若线程在 park 中被 interrupt()，会立即抛出 InterruptedException，state 不变，调用方需自行处理中断信号
• 带超时的 get(long timeout, TimeUnit unit)：底层调用 LockSupport.parkNanos()，支持纳秒级精度超时；超时后自动返回，不抛异常，但需手动检查是否 done（isDone() == false 表示超时未完成）
• 注意：超时返回后，任务仍在后台运行，Future 本身不会取消它，除非显式调用 cancel(true)

并发环境下 get() 的线程安全关键点

多个线程同时调用同一个 Future 实例的 get() 是安全的，因为状态变更和等待逻辑都受 AQS 内置锁保护。但需注意以下边界情况：

• 任务执行中被 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()）

Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南