futuretask 的状态管理在 jdk 9+ 全面基于 varhandle，通过 volatile int state 字段配合 value.getvolatile、setopaque、compareandset 等原子操作实现线程安全；其 aqs 继承仅用于线程排队，状态判断完全解耦；jdk 17 后彻底移除 unsafe，反射修改 state 已被禁止。
FutureTask 的核心同步机制依赖于 AQS（AbstractQueuedSynchronizer），其状态管理在 JDK 9 之后已全面转向 VarHandle，不再直接暴露或操作 AQS 的 state 字段。这不是简单替换，而是语义升级：从“手动维护整数状态”变为“通过类型安全、内存模型受控的原子操作访问状态字段”。
FutureTask 的三种核心状态由 VarHandle 精确控制
FutureTask 内部定义了三个 final 状态常量：NEW（0）、COMPLETING（1）、NORMAL/EXCEPTIONAL/CANCELLED/INTERRUPTING/INTERRUPTED（2–6）。这些值不再靠开发者读写 state 字段，而是通过静态初始化的 VarHandle 实现原子更新：
-
状态读取：使用
VALUE.getVolatile(this)，等价于 volatile 读，保证可见性 -
状态设置：使用
VALUE.setOpaque(this, newState)（非阻塞写）或VALUE.setVolatile(this, newState)（带释放语义） -
CAS 更新：使用
VALUE.compareAndSet(this, expect, update)，是 FutureTask 所有状态跃迁（如 NEW → COMPLETING）的唯一合法路径
AQS 的 state 字段在 FutureTask 中已被逻辑隔离
FutureTask 继承自 AQS，但重写了 tryAcquire 和 tryRelease 等模板方法，并不依赖 AQS 的 int state 做业务状态存储。它把 AQS 仅用作线程排队与唤醒的基础设施——等待线程被挂起在 AQS 队列中，而“任务是否完成”“结果是否就绪”等判断全部基于自身独立的 volatile + VarHandle 状态字段。这种解耦让 FutureTask 在 JDK 21+ 虚拟线程环境下仍能保持低开销调度。
JDK 17 至 JDK 25 的实际演进表现
现代 JDK（17 及以后）中，FutureTask 的源码已完全移除对 Unsafe 的直接引用。所有底层原子操作均由 JVM 保障的 VarHandle 实例驱动：
- 静态块中通过
MethodHandles.lookup().findVarHandle(...)获取state字段的 VarHandle，且该字段声明为volatile int state - JVM 对 VarHandle 的优化（如内联、屏障插入）比旧版 Unsafe 更稳定，避免了因类加载顺序或反射权限导致的运行时异常
- 在 JDK 25 中，FutureTask 还配合 AbstractSelector 的中断协议，在
get()阻塞期间支持被虚拟线程中断，其唤醒路径也经由 VarHandle 更新状态后触发 AQS 的 unpark
开发者无需也不应绕过 VarHandle 直接操作 state
过去有人通过反射修改 FutureTask 的 state 字段来强制完成任务，这在 JDK 9+ 已不可行——VarHandle 初始化后会绑定字段访问权限，反射绕过将抛出 IllegalAccessException 或触发 JVM 安全检查。正确做法是：
- 使用
cancel(true)请求取消并中断执行线程 - 通过
completeExceptionally()（JDK 8+）或complete()（需继承扩展）注入结果 - 在自定义 Future 实现中，优先复用 CompletableFuture，它原生基于 VarHandle + 线程本地栈，比 FutureTask 更轻量
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
