Java线程池任务超时控制需通过Future.get(timeout)主动设限、cancel(true)协同清理、分层兜底实现：任务须响应中断，资源须finally释放，线程池应配有限队列、合理保活时间及CallerRuns拒绝策略。
Java线程池本身不提供单任务执行时长的硬性限制，但通过 Future.get(timeout, unit) 配合合理设计，能有效实现任务级超时控制。关键不在“等它超时”，而在“主动设限+协同清理+分层兜底”。
用 Future.get(timeout) 主动等待并响应超时
这是最直接的任务超时入口。提交 Callable 任务后，必须用带参的 get 方法，而非无参阻塞版本：
- 调用
future.get(5, TimeUnit.SECONDS)，主线程最多等 5 秒 - 超时抛出
TimeoutException，此时应立即调用future.cancel(true) -
cancel(true)会向执行线程发送中断信号，但效果取决于任务是否响应中断
任务内部必须配合中断检查
仅调用 cancel 并不能保证任务停止——线程是否真正退出，取决于任务代码是否尊重中断信号：
- 在循环体中定期调用
Thread.currentThread().isInterrupted()，发现中断即主动退出 - I/O 操作优先选用支持中断的 API：如
Socket.setSoTimeout()、HttpURLConnection.setConnectTimeout() - 避免使用无法中断的阻塞调用，例如无超时的 JDBC 查询、
Thread.sleep(Long.MAX_VALUE)或未包装的Object.wait()
超时后资源必须自动释放
任务被取消时若正持有数据库连接、文件流或网络 socket，极易泄漏。不能依赖主线程关闭（它已放弃等待）：
立即学习“Java免费学习笔记（深入）”；
- 把 Closeable 资源声明在 try-with-resources 块内，但需确保该块在中断发生时仍能执行
- 更稳妥的做法是：在 Callable 内部用
finally块统一 close，且判断中断状态不影响清理逻辑 - 可借助
Thread.onSpinWait()或共享 volatile 标志位，让执行线程与主线程感知彼此生命周期
线程池配置要为超时策略托底
Future 超时只是应用层控制，底层线程池需同步优化，防止超时任务堆积或空闲线程滞留：
- 禁用无界队列，改用
ArrayBlockingQueue(200)，容量建议为 maxThreads × 1.5 - 设置
keepAliveTime = 60L秒，并开启allowCoreThreadTimeOut(true)，让核心线程也能回收 - 拒绝策略推荐
CallerRunsPolicy：当队列满+线程满时，由调用方线程同步执行，天然形成反压，暴露瓶颈
