futuretask 通过 volatile state 状态机和 happens-before 规则保障结果可见性与状态一致性，outcome 虽非 volatile，但借 state 的内存语义安全发布；异常统一封装为 executionexception，cancel 也走异常路径；其线程安全依赖正确调用方式。
FutureTask 本身不直接“确保结果安全性”，而是通过状态管理、内存可见性控制和线程协作机制，保障异步计算结果在多线程环境下**可正确读取、不丢失、不脏读**。它不提供业务逻辑层面的安全（比如数据加密或权限校验），而是聚焦于并发编程中最基础也最关键的两项：**结果的可见性**和**状态的一致性**。
状态机驱动，靠原子更新保证一致性
FutureTask 内部用 volatile int state 表示任务生命周期（NEW → COMPLETING → NORMAL/EXCEPTIONAL/CANCELLED 等）。所有状态变更都通过 Unsafe.compareAndSwapInt 原子操作完成，杜绝中间态被多个线程同时修改。比如任务完成时，必须先将 state 设为 COMPLETING，再写入 outcome，最后设为 NORMAL——这个顺序由 JVM 内存模型的 happens-before 关系严格约束。
- state 变为 NORMAL 的前提，是 outcome 已赋值完毕
- get() 方法只在 state > COMPLETING 时才返回 outcome，否则阻塞等待
- 因此只要 get() 返回了值，outcome 必然已写入且对调用线程可见
outcome 字段虽无 volatile，但受状态保护
outcome 是普通 Object 字段，未加 volatile，但它不是独立存在的变量——它的读写始终与 state 耦合。JVM 规范规定：对 volatile 变量的写操作，会刷新之前所有普通变量的值到主内存；对 volatile 变量的读操作，会重新加载之后所有普通变量的最新值。FutureTask 正是利用这一规则，让 outcome 的写入和读取“搭乘” state 的 volatile 语义，实现安全发布。
- set(V v) 中：先写 outcome，再写 state = NORMAL
- get() 中：先读 state，确认 ≥ NORMAL 后才读 outcome
- 两次 volatile 读写之间夹着的 outcome 操作，天然获得可见性保障
异常结果同样被统一封装和传递
如果 Callable 抛出异常，FutureTask 不会吞掉它，而是捕获后存入 outcome（实际存储的是 ExecutionException 包装后的 Throwable），同时将 state 设为 EXCEPTIONAL。后续调用 get() 时，直接 re-throw 这个 ExecutionException，业务方能准确拿到原始异常 cause。
- 避免“静默失败”：不调用 get() 就永远看不到异常，但异常确实存在且已保存
- 异常和正常结果使用同一套 outcome + state 机制，语义统一
- cancel(true) 触发中断时，若任务正在运行，也会走 setException(new CancellationException()) 路径
线程安全使用的关键不在 FutureTask 自身，而在调用方式
FutureTask 实例本身是线程安全的（状态和 outcome 访问受控），但误用仍会导致结果不可靠：
- 禁止在多个线程反复调用同一个 FutureTask 的 run() —— 它只应执行一次
- 避免在未完成时反复调用 get() 且不设超时，可能无限阻塞
- 不要把 FutureTask 当作共享缓存：每个异步任务应有独立实例，不复用
- 若需多次获取结果，应自行缓存 get() 返回值，而非反复调用
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
