Future.get(long, TimeUnit) 超时仅终止等待而非任务本身，因任务线程阻塞时不响应中断；cancel(true) 是否生效取决于任务是否检查并处理中断信号。
Future.get(long timeout) 为什么有时根本不超时？
根本原因：get(long, TimeUnit) 的超时只作用于「等待任务完成」这一阶段，如果任务本身正在执行且未结束，超时时间到了就会抛出 TimeoutException；但如果任务已进入阻塞态（比如在 Thread.sleep()、Object.wait()、IO 等待中），它并不会被中断——超时只是让调用方放弃等待，不是终止任务本身。
- 常见错误现象：
get(1, TimeUnit.SECONDS)调用后主线程卡住十几秒甚至更久 - 真实原因：任务线程在执行一个不响应中断的阻塞操作（如老式 JDBC 查询、无超时的 Socket.read()）
- 关键点：
Future不控制任务线程生命周期，它只提供「查询+等待」能力 - 验证方式：在任务里加
Thread.currentThread().isInterrupted()，你会发现超时后任务线程并未被中断（除非你手动调用future.cancel(true)）
cancel(true) 能真正中断运行中的任务吗？
不能一概而论。是否中断成功，完全取决于任务代码是否检查并响应中断信号。
- 能中断的情况：任务中主动调用
Thread.sleep()、BlockingQueue.take()、CountDownLatch.await()等可中断方法，它们会在收到中断时抛出InterruptedException - 不能中断的情况：纯计算循环、
System.in.read()、未设置 SO_TIMEOUT 的Socket.getInputStream().read()、synchronized 块内等待锁 - 必须配合使用：
future.cancel(true)只是设置中断标志 + 尝试中断阻塞点，任务体里还得有对应的异常捕获和退出逻辑 - 典型陷阱：写了
catch (InterruptedException e) { Thread.currentThread().interrupt(); }却没 break/return，结果任务继续跑
如何避免主线程因 get() 永久阻塞？
核心思路：别依赖单次 get() 完成所有等待，改用轮询 + 显式中断控制。
- 用
isDone()配合短时get(100, TimeUnit.MILLISECONDS)循环，每次失败都检查是否该退出 - 启动任务前，确保其内部对中断敏感：比如数据库连接加
socketTimeout，HTTP 客户端设connectTimeout和readTimeout - 若必须用
get(long, TimeUnit)，务必在外层 try-catchTimeoutException，并立即调用future.cancel(true)尝试清理 - 注意线程池配置：如果用的是
Executors.newCachedThreadPool()，被 cancel 的线程可能不会立刻回收，残留线程会持续占用资源
CompletableFuture 有没有更靠谱的替代方案？
有，但不是“自动解药”，而是把中断责任显式化、可组合化。
-
orTimeout(long, TimeUnit)会在超时后返回一个以TimeoutException完成的 CompletableFuture，但它同样不中断底层任务 -
completeOnTimeout(V, long, TimeUnit)是用默认值“假装完成”，更适合容错场景，而非取消任务 - 真要中断，还是得靠
whenComplete((r, t) -> { if (t instanceof TimeoutException) future.cancel(true); })这类手动联动 - 重要提醒：JDK 19+ 引入了
StructuredTaskScope，支持真正的父子任务中断传播，但目前需手动管理作用域生命周期，生产环境慎用
超时机制本身很干净，麻烦永远出在任务怎么写——只要有一处阻塞不响应中断，整个链路就不可控。别迷信接口名里的 “timeout”，它只管等，不管停。
