future.cancel(true) 不生效的根本原因是任务未响应中断信号，需主动检查中断状态或使用可中断api；cancel(false)仅标记状态，几乎无实际用途。
Future.cancel 为什么经常不生效
根本原因不是 Future.cancel 写错了，而是它默认只“中断线程”，不终止正在执行的逻辑。如果任务代码没响应中断（比如没检查 Thread.interrupted()、没捕获 InterruptedException、或在阻塞 I/O 中卡死），cancel(true) 就只是发了个信号，任务照常跑完甚至卡住。
常见错误现象：Future.isCancelled() 返回 true，但线程池里线程数没降、数据库连接没释放、文件句柄持续占用。
- 任务必须主动配合中断：在循环中加
if (Thread.currentThread().isInterrupted()) return; - 阻塞调用要能响应中断：用
Thread.sleep()而非TimeUnit.SECONDS.sleep()（后者内部也是调用前者，但要注意封装层是否吞了异常） - IO 操作需可中断：优先选 NIO（如
SocketChannel），避免传统InputStream.read()这类无法被中断的阻塞调用
cancel(true) 和 cancel(false) 的实际区别
cancel(true) 会调用 Thread.interrupt()；cancel(false) 只标记状态，不打扰线程执行。多数场景下，false 几乎没用——除非你确定任务本身是纯检测型、无副作用、且已内置轮询退出逻辑。
性能与兼容性影响：中断本身开销极小，但若任务频繁忽略中断并继续运行，会导致线程长期占用、GC 压力上升、连接池耗尽等连锁问题。
- 不要对
CompletableFuture直接调cancel(true)：它不响应中断，得靠completeExceptionally(new CancellationException())配合外部逻辑清理 - 使用
ExecutorService.invokeAll(Collection extends Callable<t>>, long, TimeUnit)</t>时，超时后返回的List<future>></future>中已取消的项，仍需手动检查并清理资源 - 自定义
ThreadFactory时，别把线程设为守护线程（setDaemon(true)），否则可能在任务中途被 JVM 强制回收，导致资源未关闭
超时后资源泄露的典型场景和补救点
最常漏掉的是“取消后没关资源”，不是 cancel 失败，而是 cancel 成功了，但程序员忘了在 finally 或回调里做清理。
使用场景举例：HTTP 请求 + 数据库写入 + 本地缓存更新。超时发生时，可能 HTTP 客户端已释放连接，但数据库事务还开着，缓存还锁着。
- 所有资源获取操作（DB connection、HTTP client、FileInputStream）必须放在 try-with-resources 或显式
finally块中，不能依赖任务自然结束 - 避免在
Future.get()外层包一层大 try-catch 吞掉CancellationException，否则清理逻辑进不去 - 考虑用
tryComplete或whenComplete替代裸get()，确保无论成功、异常、取消都能触发统一清理钩子
替代方案：比 Future.cancel 更可控的超时控制
当任务不可中断或第三方库不支持中断时，Future.cancel 就是纸面功能。这时候得换思路：不靠“中断”，而靠“隔离+强制回收”。
参数差异关键点：超时单位、线程模型、资源生命周期绑定方式。
- 用
Executors.newSingleThreadScheduledExecutor()启动监控线程，超时后调process.destroyForcibly()（仅限子进程场景） - 对 DB 操作，设置 JDBC URL 的
socketTimeout和queryTimeout，比 Java 层 cancel 更底层有效 - Spring 环境下，优先用
@Async(timeout = 5000)+TaskScheduler，它会在超时后自动触发Future.cancel(true)并尝试清理上下文
复杂点在于：没有银弹。中断是否生效，取决于任务代码是否“守规矩”。最容易被忽略的，是那些看似无害的 while 循环里没加中断检测——它不会报错，只会让整个系统慢慢变僵。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
