Future.isCancelled() 仅表示取消请求是否发出，不保证任务已停止；其返回true时任务可能仍在运行，需在任务内部主动检查中断或轮询isCancelled()才能实现真正取消。
Future.isCancelled() 的真实行为边界
Future.isCancelled() 只反映任务是否被显式调用 cancel(true) 或 cancel(false) 触发过取消请求，它不关心线程是否真正停止、资源是否释放，也不感知“用户手动取消”的 UI 动作本身——那只是你代码里某次 future.cancel() 调用的源头。
换句话说：这个方法查的是“取消信号有没有发出去”，不是“任务是不是已经收手了”。常见误解是以为它能返回 true 就代表任务已退出执行，但实际中，isCancelled() 返回 true 时，线程可能还在跑（尤其没响应中断时）。
为什么调用 cancel() 后 isCancelled() 有时仍为 false
根本原因是未正确传递取消意图到任务内部。典型场景包括：
- 提交的是一个不检查
Thread.interrupted()或不响应InterruptedException的Runnable，cancel(true)发送中断后任务继续执行，isCancelled()却已返回true（因为取消请求已记录），但任务逻辑毫无感知 - 使用
CompletableFuture时直接构造而未绑定取消逻辑，比如CompletableFuture.supplyAsync(() -> heavyWork())，调用cancel(true)不会中断底层线程池线程，isCancelled()返回true，但heavyWork()照常跑完 - 自定义
FutureTask但重写了done()却忘了在run()中定期轮询isCancelled()
让 isCancelled() 有实际意义的三个必要动作
要使 isCancelled() 的返回值真正对应“任务已中止”，必须在任务体内部主动配合：
- 在循环体开头或耗时操作间隙插入
if (Thread.currentThread().isInterrupted()) return;或抛出InterruptedException - 对阻塞调用（如
Thread.sleep()、BlockingQueue.take()）做好异常捕获，并在catch (InterruptedException e)块中立即退出或重新设置中断状态：Thread.currentThread().interrupt(); - 若使用
ExecutorService提交FutureTask，确保其run()方法内有类似这样的防护：protected void run() { if (isCancelled()) return; try { // 实际逻辑 } finally { // 清理 } }
CompletableFuture 场景下 isCancelled() 的局限性
CompletableFuture 默认不支持取消传播——它的 cancel() 方法只是把状态设为完成并带异常（CancellationException），不会中断正在执行的异步线程。这意味着：
-
cf.cancel(true)后，cf.isCancelled()返回true，但原始任务线程可能仍在运行 - 若需真正中断，得自己封装：例如用
Thread+AtomicBoolean控制，或改用ManagedExecutor（Jakarta EE）等支持取消上下文的执行器 - 检查取消状态不能只靠
isCancelled()，建议组合使用：!cf.isDone() && cf.isCancelled()表示“尚未结束且已被取消”，但仍需任务体自行响应
真正可靠的取消永远依赖任务代码里的主动轮询和中断处理，isCancelled() 只是那个微小但关键的布尔开关。漏掉内部响应，它就只是个“已按过取消键”的日志标记。
