futuretask结果不可变，所谓“覆写”实为误用：共享实例提交多次、集合中替换future引用、拒绝策略致状态卡在new，均非真覆写；正确解法是用atomicreference、completablefuture或resultholder封装。
FutureTask 本身不支持“覆写结果”，所谓“结果被覆写”其实是误用导致的逻辑错觉或状态混乱，根本原因在于对 FutureTask 不可变性、线程安全边界和生命周期状态的理解偏差。
FutureTask 的结果不可变是硬约束
FutureTask 实现了 Future 接口，其设计原则是：一旦任务完成（NORMAL 或 EXCEPTIONAL 状态），结果就固化，无法被再次设置或修改。内部 state 字段通过 CAS 控制状态流转（NEW → COMPLETING → NORMAL/EXCEPTIONAL），且 set()、setException() 等写入方法仅在状态为 NEW 时才生效。多次调用 run() 不会重复执行 callable，也不会覆盖结果；而手动调用 set()（需反射绕过访问控制）属于破坏封装的非法操作，不在规范使用范围内。
常见被误认为“覆写”的三类场景
- 共享同一个 FutureTask 实例提交多次：FutureTask 是 Runnable 和 Future 的合一实现，但 它不是可重入任务容器。若将同一 FutureTask 对象反复 submit 给线程池，第二次 submit 可能因状态已非 NEW 而静默失效，或触发拒绝策略；若线程池复用线程且未清理状态，可能造成 get() 返回旧结果或阻塞——这不是覆写，而是状态残留或调用时机错误。
-
用 List
> 存储后试图直接赋值替换元素 ：例如list.set(i, someInt)会编译失败（类型不匹配），而list.set(i, new FutureTask(...))虽语法合法，但只是替换了 Future 引用，原任务仍在运行，新 Future 与旧结果无任何关系。用户感知的“覆写”实为集合引用变更，非 FutureTask 内部数据被改写。 -
线程池拒绝策略导致 Future 状态卡在 NEW：当使用 DiscardPolicy 或 DiscardOldestPolicy 时，被丢弃任务对应的 FutureTask 状态仍为 NEW，后续调用
get()会无限阻塞（因 state 永远 ≤ COMPLETING）。此时若误以为“结果被覆盖”，实则是 Future 从未完成，更谈不上覆写。
真正需要“更新结果”的正确解法
若业务确实需要异步计算后动态修正结果（如重试、补偿、聚合），不应依赖 FutureTask 本身，而应：
- 用线程安全容器承载结果，例如
AtomicReference<t></t>或ConcurrentHashMap，由任务写入，其他线程读取并更新； - 采用 CompletableFuture，它支持 thenApply、whenComplete、completeAsync 等链式更新能力，天然支持结果的后续变换与手动完成；
- 封装一层 ResultHolder 类，内部用 volatile + synchronized 控制写入权限，并提供版本号或时间戳避免脏写。
规避边界缺陷的关键实践
- 每个逻辑任务创建独立 FutureTask 实例，禁止复用；
- 永远使用带超时的
get(long, TimeUnit)，避免因拒绝策略或死锁导致永久阻塞； - 提交任务后，不再尝试干预 FutureTask 内部状态，只通过标准 Future API 观察和获取；
- 日志中记录 FutureTask 的 hashCode 和任务标识，便于排查是否意外复用同一实例。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
