futuretask是天然的状态机载体，依托7种原子状态和volatile+ cas机制实现任务执行与结果消费解耦。它适用于多栏目看板场景，支持独立加载、取消、阻塞获取与终态判断，无需手动状态管理。
在多栏目看板这类需要并行加载、按需响应、状态强一致的场景中，FutureTask 不是拿来“手动管理状态”的工具，而是天然的状态机载体。它不依赖外部状态管理框架，靠自身 7 种原子状态（NEW → COMPLETING → NORMAL/EXCEPTIONAL/CANCELLED 等）和 volatile + CAS 的协作机制，就能让“任务执行”与“结果消费”解耦，同时保证线程安全。关键不在“怎么绑定”，而在“怎么信任并用好它内置的状态流转逻辑”。
一、为什么看板场景特别适合 FutureTask 内置状态机
多栏目看板通常有多个数据源（如用户画像、实时订单、库存预警、运营活动），每个栏目独立异步加载，但又存在共性约束：
- 栏目 A 加载失败不能阻塞栏目 B；各栏目任务彼此隔离
- 用户下拉刷新时，需取消旧请求、触发新请求——cancel(true) 能中断正在 run() 的线程
- 点击某个栏目跳转详情页，需确保该栏目数据已就绪或已失败——get() 自动阻塞或抛异常，无需额外判空/判状态
- 后台切前台时批量重试失败栏目——isDone() + isCancelled() + getNow(null) 可无锁判断当前终态
二、不写状态同步代码：直接复用 FutureTask 的状态跃迁
FutureTask 把状态推进完全封装在 run() 和 set()/setException() 中。你只需专注业务逻辑，状态自动流转：
- new FutureTask(callable) → state = NEW
- 调用 futureTask.run() → 若未被 cancel，则 state 原子变更为 RUNNING（内部通过 CAS 更新 runner）
- callable.call() 正常返回 → set(v) → state 先变为 COMPLETING（短暂中间态），再变为 NORMAL
- callable.call() 抛异常 → setException(ex) → state 同样经 COMPLETING → EXCEPTIONAL
- futureTask.cancel(true) 在运行中 → 中断 runner 线程，并将 state 设为 INTERRUPTING → INTERRUPTED
- cancel(false) 或已开始执行 → state 变为 CANCELLED（仅标记，不中断）
这些跃迁全部由 FutureTask 内部完成，你不需要 synchronized、不需要 ReentrantLock、也不需要自己维护 volatile boolean isLoaded。
三、看板交互中的典型操作与对应 FutureTask 方法
以“用户行为触发数据加载/刷新/取消”为例，直接映射到 FutureTask 原生语义：
- 首次加载栏目 X：new FutureTask(new DataCallable("user-profile")) → submit 或 new Thread().start()
- 下拉刷新栏目 X：if (!futureTask.isDone()) futureTask.cancel(true); futureTask = new FutureTask(...); start again
- 点击进入栏目 X 详情页：try { String data = futureTask.get(5, TimeUnit.SECONDS); } catch (TimeoutException e) { showLoadingPlaceholder(); }
- 后台聚合展示“加载成功率”：futureTask.isDone() && !futureTask.isCancelled() → 成功；isCancelled() → 主动放弃；isDone() && !isCancelled() && getNow(null) == null → 异常失败（需捕获 get() 或检查 outcome）
四、注意事项：避免绕过状态机破坏一致性
FutureTask 的安全性建立在“所有状态变更只经由其内部方法触发”这一前提上。实战中容易踩坑的操作：
- ❌ 手动修改 outcome 字段（反射或 Unsafe）→ 破坏 state/outcome 一致性，get() 可能返回 null 或错误异常
- ❌ 多次调用 run() → 第二次 run() 直接 return（state 已非 NEW），但业务 callable 可能被重复执行（若未加幂等控制）
- ❌ 在 callable 中自行 notify/wait 或使用 CountDownLatch → 干扰 FutureTask 自带的 Treiber 栈 waiters 唤醒机制，导致 get() 永远阻塞
- ✅ 推荐做法：所有异步逻辑封装进 Callable；状态判断统一用 isDone()/isCancelled()/isCompletedExceptionally()；结果获取只走 get()/getNow()
FutureTask 的状态机不是要你去“绑定”或“驱动”，而是让你放手，让它在并发边界内安静地完成所有原子跃迁。多栏目看板的复杂交互，恰恰需要这种确定性——不是越可控越安全，而是越少干预越可靠。
