FutureTask.cancel(true)仅发送中断信号，无法强制终止任务；真正生效依赖任务代码主动检查Thread.isInterrupted()或响应可中断阻塞点。
在调用 FutureTask.cancel(true) 时，JVM 并不保证底层物理线程能立即、可靠地感知中断状态。真正起作用的是线程自身的中断检测逻辑（如 Thread.interrupted() 或阻塞点的中断响应），而 cancel(true) 只是设置中断标志 + 中断线程。但若线程正忙于非阻塞计算（比如密集轮询、无锁自旋、纯 CPU 循环），它可能长期不检查中断，导致 cancel 失效 —— 这不是 bug，而是 Java 内存模型与线程协作语义的自然结果。
理解“条件可见性屏障”的真实含义
Java 中没有叫“条件可见性屏障”的标准术语。你实际需要的是：确保中断标志（Thread.interrupted() 所读取的状态）对目标线程的轮询逻辑是及时可见的。这依赖两个层面：
-
volatile 语义保障：JVM 将
Thread.interrupt()实现为对线程内部interrupted标志的 volatile 写操作，因此其他线程的后续 volatile 读（如Thread.interrupted()）能看见该写入 —— 无需手动加屏障。 -
轮询逻辑必须主动读取中断状态：仅靠 volatile 不够；线程必须在循环中显式调用
Thread.interrupted()或isInterrupted()，且不能被 JIT 优化掉（例如避免空循环、避免把中断检查提到循环外）。
让轮询线程可靠响应中断的写法
错误写法：
while (running) { /* heavy computation, no interrupt check */ }
即使调用了 cancel(true)，该线程永不退出。
正确写法（推荐）：
- 在每次迭代或关键检查点插入
if (Thread.currentThread().isInterrupted()) break; - 若轮询体包含阻塞调用（如
LockSupport.parkNanos(),Queue.poll(timeout)），它们天然响应中断，无需额外处理 - 避免用
Thread.interrupted()（会清中断标志），除非你明确要消费并重置它；轮询场景用isInterrupted()更安全 - 若循环极轻量（如 CAS 自旋），可配合
Thread.onSpinWait()（JDK9+）提示 CPU 优化，但不替代中断检查
cancel() 调用前不需要额外内存屏障
FutureTask.cancel(true) 内部已调用 thread.interrupt()，而该方法本身具有 volatile 写的语义，等价于一次完整的内存屏障（JSR-133 规定）。你无需、也不应手动插入 Unsafe.storeFence() 或 VarHandle.acquireRelease 等底层屏障 —— 这不仅多余，还可能破坏 JVM 对中断路径的优化假设。
唯一需关注的是：确保你的轮询代码运行在被中断的那个线程上，并且它的中断检查未被编译器/JIT 意外消除（可通过 -XX:+PrintAssembly 验证，或加入 volatile 读/写作为防优化锚点）。
调试与验证技巧
当 cancel 似乎不生效时，优先排查：
- 目标线程是否真的执行了你写的轮询逻辑？用
jstack <pid>查看线程栈，确认它卡在预期位置 - 轮询循环里是否有
try-catch(InterruptedException)却没重设中断？漏掉Thread.currentThread().interrupt()是常见陷阱 - 是否误将
FutureTask提交到线程池后，又在外部线程反复调用cancel()？cancel 只能调用一次，重复调用返回 false，但无副作用 - 使用
Thread.getAllStackTraces().keySet()或 JMX 监控确认线程存活状态，排除已自然终止却被误认为“未响应 cancel”
