Java中无法强制杀死线程，超时中断本质是协作式通知；需结合Future超时获取、任务可中断设计（轮询检查中断+使用可中断API）、线程池有序关闭（shutdown/awaitTermination/shutdownNow）三者实现可靠超时控制。
Java 中无法“强制杀死”线程，超时中断本质是协作式通知。要真正清理卡死或无响应的任务，必须把“超时监控”和“任务可中断性”两层逻辑结合起来，再配合线程池的有序关闭机制——不是靠单点 interrupt()，而是靠结构化设计。
用 Future + 带超时的 get() 主动控制任务生命周期
这是最标准、最可控的起点。提交任务后不盲等，而是限定等待窗口：
- 调用 future.get(5, TimeUnit.SECONDS)，超时抛出
TimeoutException - 捕获异常后立即执行 future.cancel(true)，尝试中断执行线程
- 注意：cancel(true) 是否生效，取决于任务内部是否检查中断（如循环中调用
Thread.currentThread().isInterrupted()） - 避免使用
Executors.newCachedThreadPool()，它可能无限创建线程；推荐直接构造ThreadPoolExecutor并显式配置队列与拒绝策略
让任务自身支持中断：轮询 + 可中断点双保险
很多任务卡在纯计算循环里，interrupt() 信号完全无效。必须让任务“自己愿意停下来”：
- 所有长循环开头或关键迭代点，插入
if (Thread.currentThread().isInterrupted()) { cleanup(); return; } - 阻塞操作优先选可中断版本：用
BlockingQueue.poll(timeout, unit)替代take()，用Socket.setSoTimeout()替代阻塞 read() - 捕获
InterruptedException后，必须立刻重设中断标志：Thread.currentThread().interrupt();，否则上层 cancel 会失效 - 不要用
catch (Exception e) { }吞掉异常，中断信号就此消失
线程池关闭阶段清理残留任务
即使单个任务已超时取消，线程池本身仍需安全退出，防止资源泄漏：
- 调用 shutdown() 停止接收新任务，但允许已提交任务（含队列中等待的）继续执行
- 紧接着调用 awaitTermination(30, SECONDS) 等待自然结束；若返回 false，说明仍有任务未完成
- 此时可选 shutdownNow() 尝试中断所有活跃线程并清空队列——但前提是这些任务已按前述方式支持中断
- 为防多处并发触发关闭，用 volatile boolean isShuttingDown 做入口保护，只执行一次 shutdown()
补充：避免守护线程误用
设置 thread.setDaemon(true) 和超时控制无关。守护线程不会帮你倒计时、不会主动中断别人、JVM 退出时它会被静默终止——没有清理机会。超时必须由独立监控方（如定时器、主线程、另一个 Executor）发起，不能依赖被监控线程自己是 daemon。
