futuretask能同时执行与获取结果是因为其基于状态机（volatile state字段）和同步机制（locksupport.park/wait-notify）实现任务生命周期控制，而非接口继承；run()幂等，仅new态执行；cancel(true)仅设中断标志，依赖任务体响应；不可重复使用。
FutureTask 为什么能同时被线程执行又支持结果获取
因为它的核心是把 Runnable 或 Callable 封装进一个可状态流转的容器，内部用 state 字段（int 类型）控制生命周期，配合 wait/notify 或 LockSupport.park 实现阻塞等待。不是靠继承两个接口实现“双重身份”，而是靠状态机 + 同步机制桥接执行与结果。
常见错误现象：get() 调用后线程一直挂起不返回；run() 执行完但 isDone() 仍为 false；多个线程反复调用 run() 导致任务重复执行。
-
FutureTask的run()方法是幂等的：只有在state == NEW时才会真正执行任务体，否则直接返回 - 一旦进入
COMPLETING或NORMAL/EXCEPTIONAL状态，就不可逆，后续所有get()都会立即返回或抛异常 - 不要手动调用
run()多次——它不是普通方法，而是状态跃迁的入口，交给Thread或线程池调度才安全
submit(Runnable, T) 和 new FutureTask(Runnable, T) 的行为差异
两者看似都能传入 Runnable 和默认返回值，但底层对“任务是否真被运行”的判断逻辑不同，容易导致 get() 返回意料之外的值或空指针。
使用场景：你想让一个无返回值的任务也能通过 Future 接口统一处理，比如日志上报、异步清理等。
-
ExecutorService.submit(Runnable task, T result)底层会新建一个FutureTask，并把result存在私有字段里；即使任务没执行完，get()也会返回这个result -
new FutureTask(Runnable, T)构造时就把result绑定到实例，但它的get()只有在任务完成（state >= COMPLETING）后才返回该值；否则阻塞 - 如果任务抛异常，前者仍返回你传的
result；后者则抛出ExecutionException包裹原始异常
cancel(true) 不一定能中断正在运行的线程
这是最常被误解的一点：cancel(true) 只是设置中断标志 + 尝试 interrupt() 当前执行线程，但能否真正停下，完全取决于任务体内部是否响应中断。
常见错误现象：cancel(true) 返回 true，但线程仍在跑；isCancelled() 为 true，而 isDone() 却还是 false。
- 任务代码里必须显式检查
Thread.interrupted()或捕获InterruptedException，否则中断信号会被忽略 - 阻塞 I/O（如
SocketInputStream.read()）、Object.wait()、Lock.lockInterruptibly()这类操作会响应中断；纯计算循环不会 -
cancel(false)表示“只取消未启动的任务”，已开始运行的不受影响，此时isCancelled()为true，但isDone()仍为false，直到它自己结束
FutureTask 在线程池中重复使用会出问题
FutureTask 是一次性对象，状态变更不可逆，不能像 Runnable 那样多次提交给线程池复用。
性能影响：重复使用会导致 run() 直接跳过、get() 返回旧结果或抛异常，还可能因状态混乱引发并发问题。
- 每次提交新任务，都应创建新的
FutureTask实例 - 不要把同一个
FutureTask对象传给多个execute()或submit()调用 - 如果想复用逻辑，应封装成工厂方法或 lambda，而不是复用
FutureTask实例本身
最容易被忽略的是：它的 state 字段是 volatile 但非原子更新，所有状态跃迁都依赖 UNSAFE.compareAndSwapInt，一旦初始状态不是 NEW，整个流程就绕过了任务执行环节——这点在单元测试里特别容易漏掉验证。
