Future 和 FutureTask 是 Java 异步结果的占位符，通过 AQS 的 state 状态机（NEW→COMPLETING→NORMAL/EXCEPTIONAL 等）控制 get() 阻塞等待或 cancel() 取消，严禁轮询；应优先使用带超时的 get() 并妥善处理异常。
Future 和 FutureTask 是 Java 并发编程中获取异步计算结果的核心工具。它们不直接执行任务，而是作为“结果占位符”存在，关键在于如何安全、高效地拿到结果——主要靠 阻塞等待（get()）或 状态轮询（isDone()），而背后的状态流转由一组精确控制的变量驱动。
阻塞获取结果：线程挂起与唤醒机制
调用 future.get() 时，当前线程不会空转，而是进入 WAITING 状态，直到任务完成被唤醒。这不是忙等，而是基于 AQS（AbstractQueuedSynchronizer）实现的 park/unpark 机制：
- FutureTask 内部使用 AQS 的 state 字段表示任务状态（如 NEW、COMPLETING、NORMAL 等），get() 对应 acquire 操作，会检查 state 是否已达终态
- 若未完成，线程被加入 AQS 的等待队列，并调用
LockSupport.park()挂起 - 当 run() 执行完毕或 cancel() 被调用，会触发 release 操作：更新 state、设置 outcome（结果或异常）、遍历并 unpark 所有等待线程
- 被唤醒的线程重新检查 state，若已完成则返回 outcome；否则继续 park（避免虚假唤醒）
轮询方式的风险与适用边界
用 while(!future.isDone()) { Thread.sleep(10); } 主动轮询是反模式，原因明确：
- CPU 白耗：即使休眠 10ms，频繁调用仍造成调度开销和上下文切换压力
- 响应延迟：任务在 sleep 中间完成，线程要等到下一次循环才感知，引入不可控延迟
- 无法区分状态：isDone() 返回 true 时，任务可能已取消或异常失败，但轮询本身不抛异常，容易掩盖问题
- 无通知语义：它只是读取一个 volatile 变量，不触发任何同步动作，与 get() 的原子等待语义完全不同
仅在极少数嵌入式或硬件协议交互场景中允许轮询，标准业务逻辑中应避免。
核心状态变量与转换逻辑
FutureTask 定义了 7 种状态，全部通过一个 volatile int state 字段维护，所有状态变更均通过 CAS 原子操作保证线程安全：
- NEW → COMPLETING：run() 开始写结果前的瞬态，此时 get() 阻塞并入队
- COMPLETING → NORMAL / EXCEPTIONAL：成功写入 result 或 exception 后，state 确定为终态
- NEW → CANCELLED：cancel(false) 在任务未启动时直接标记取消
- NEW → INTERRUPTING → INTERRUPTED：cancel(true) 先中断线程，再清理状态
- state 达到终态（≥ NORMAL）后，outcome 字段才被赋值，get() 从此可安全读取
实际使用建议
生产环境应坚持以下实践：
- 永远优先使用
get(long timeout, TimeUnit)，设合理超时（如网络请求 5s，本地计算 200ms），捕获 TimeoutException、CancellationException、ExecutionException - 避免在 UI 主线程、Servlet 请求线程等敏感上下文中调用无参 get()，防止 ANR 或请求挂起
- cancel() 调用后不必再调用 get() —— 若已取消，get() 必抛 CancellationException；若未取消，get() 行为不变
- 不要依赖 isDone() + get() 组合做“非阻塞判断”，因存在竞态：isDone() 返回 true 后，任务仍可能被并发 cancel，导致后续 get() 抛异常
