Java线程池超时控制：Future与超时机制

Java线程池本身并不提供单任务执行时长的硬性限制——这句话很多人都知道，但真正落地时，往往容易踩坑。核心思路其实很清晰：通过 Future.get(timeout, unit) 主动设限，配合 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：当队列满、线程也满的时候，由调用方线程同步执行任务，天然形成反压，把系统瓶颈直接暴露出来。