Java 线程池本身并不提供对单个任务执行时长的硬性限制——这一点许多开发者都清楚，但在实际落地时却容易踩坑。核心思路其实非常明确：通过 Future.get(timeout, TimeUnit) 主动设置超时时间，配合 cancel(true) 协同清理，再加上分层的兜底设计，才能让超时控制真正稳定可靠。
关键不在于“被动等待超时”，而在于“主动设限 + 协同清理 + 分层兜底”。下面从四个层面进行拆解。
用 Future.get(timeout) 主动等待并响应超时
这是最直接的办法——提交 Callable 任务之后，务必要使用带超时参数的 get 方法，而不是无参阻塞版本。例如：future.get(5, TimeUnit.SECONDS)，主线程最多等待 5 秒。如果发生超时，会抛出 TimeoutException，此时应立即调用 future.cancel(true)。后者会向正在执行的线程发送中断信号，但线程是否真正停止，还要看它是否配合中断处理。
任务内部必须配合中断检查
仅仅调用 cancel(true) 并不能保证任务立即停止——线程是否真正退出，关键取决于任务代码是否尊重中断信号。具体而言：
- 在循环体内部定期检查
Thread.currentThread().isInterrupted()，一旦检测到中断就主动退出循环或终止执行。 - I/O 操作优先选用支持中断的 API，比如
Socket.setSoTimeout()、HttpURLConnection.setConnectTimeout()。 - 避免使用无法中断的阻塞调用，例如无超时的 JDBC 查询、
Thread.sleep(Long.MAX_VALUE)或者未经过包装的Object.wait()。
超时后资源必须自动释放
任务被取消时，如果正持有数据库连接、文件流或网络 socket，很容易造成资源泄漏。主线程已经放弃等待，不能再指望它去关闭资源，必须依靠任务自身来兜底：
- 将
Closeable资源声明在 try-with-resources 块中，但要确保该块在中断发生时仍能执行到清理逻辑。 - 更稳妥的做法是：在
Callable内部使用finally块统一调用 close，并注意不要让中断状态干扰清理流程。 - 可以借助
Thread.onSpinWait()或共享 volatile 标志位，让执行线程与主线程能够感知彼此的生命周期状态。
线程池配置要为超时策略托底
Future 超时只是应用层面的控制，底层的线程池同样需要同步优化，以防超时任务堆积或空闲线程滞留：
- 禁用无界队列，改用
ArrayBlockingQueue(200)，容量建议设定为 maxThreads × 1.5 左右。 - 设置
keepAliveTime = 60L秒，并开启allowCoreThreadTimeOut(true)，使核心线程也能被回收。 - 拒绝策略推荐使用
CallerRunsPolicy：当队列满且线程数也达到上限时，由调用方线程同步执行任务，天然形成反压，将系统瓶颈直接暴露出来。
