FutureTask 内置线程安全机制，无需额外同步即可安全发布结果；其状态机与CAS保障任务只执行一次、volatile outcome确保结果可见、并发get()安全高效，且无需对引用加锁或声明volatile。
FutureTask 本身已内置线程安全机制，无需额外同步即可在多线程环境下安全发布结果。它的核心设计保证了任务只执行一次、结果对所有线程可见、并发调用 get() 不会引发重复计算或数据竞争。
状态机与 CAS 保障执行唯一性
FutureTask 内部维护一套严格的状态机（如 NEW → COMPLETING → NORMAL/EXCEPTIONAL），所有状态变更都通过 CAS（Compare-and-Swap）原子操作完成。这意味着：
- 仅第一个调用
run()的线程能将状态从 NEW 更新为 COMPLETING，其余线程的run()调用直接返回，不触发二次执行 - 任务执行完毕后，结果（或异常）被写入
volatile修饰的outcome字段，确保对所有线程立即可见 - 后续任意线程调用
get()都能读到同一份最终结果，不存在脏读或过期值
多线程并发 get() 的行为是安全且高效的
多个线程同时调用同一个 FutureTask 的 get() 是完全支持的典型用法：
- 若任务未完成，调用线程会进入内部等待队列并阻塞，不消耗 CPU
- 任务完成瞬间，所有阻塞线程被统一唤醒，各自获取相同结果（成功值或封装后的异常）
- 没有锁竞争，底层使用的是基于 AQS 的条件队列，性能开销低
正确发布结果的关键操作习惯
线程安全不等于使用无风险，需配合规范操作才能真正“安全发布”：
立即学习“Java免费学习笔记（深入）”；
- 只通过线程池
submit()或单次Thread.start()触发执行，禁止手动多次调用run() - 避免重复提交：同一个 FutureTask 实例不应被多次提交给 Executor，否则可能因状态不可逆导致静默失败
- 务必处理
get()抛出的ExecutionException—— 它包装了原始业务异常，忽略它等于丢掉错误上下文 - 生产环境建议优先使用带超时的
get(long, TimeUnit)，防止因任务卡死导致线程永久挂起
不需要额外同步或 volatile 声明
FutureTask 已通过 volatile 字段、CAS 和内置锁（AQS）完整覆盖内存可见性与原子性问题。即使将 FutureTask 实例赋值给共享变量，也无需对其引用本身加锁或声明为 volatile —— 它的结果发布逻辑已自包含。
