Java线程禁用stop()，应使用interrupt()协作式中断：设标志位，线程自主响应；阻塞方法抛InterruptedException并清标志，非阻塞需手动检查isInterrupted()并恢复中断状态。
Java线程不能用 stop() 强制终止，这是最常踩的坑
直接调用 Thread.stop() 会释放所有锁、破坏对象状态，JVM 早在 JDK 1.2 就已标记为 @Deprecated，现代代码里出现它基本等于埋雷。你看到的“线程没停”或“程序卡死”，大概率是强行中断后资源没清理干净导致的死锁或数据不一致。
真正能用的只有两种配合方式：interrupt() 发信号 + 主动检查退出条件。它不杀线程，只设一个中断标志位，后续行为完全由线程自己决定。
-
interrupt()是协作式通知，不是命令；线程是否响应、何时响应、怎么响应，全在你自己写的逻辑里 - 阻塞方法（如
Thread.sleep()、Object.wait()、BlockingQueue.take()）收到中断会立即抛出InterruptedException，并自动清除中断状态 - 非阻塞场景下，必须手动检查
Thread.currentThread().isInterrupted()—— 注意不是static interrupted()，后者会清标志位
如何写一个带中断响应的循环任务
绝大多数后台线程是 while 循环驱动的，比如定时拉日志、轮询数据库、消费消息队列。这种场景下，光靠捕获 InterruptedException 不够，因为循环体里可能全是计算逻辑，根本不会触发阻塞。
正确做法是把中断检查嵌进循环条件，并在 catch 块里重新设置中断状态（否则异常清除了标志，后续检查永远为 false）：
立即学习“Java免费学习笔记（深入）”；
while (!Thread.currentThread().isInterrupted()) {
try {
doWork();
Thread.sleep(1000);
} catch (InterruptedException e) {
Thread.currentThread().interrupt(); // 恢复中断状态
break;
}
}
- 循环条件用
!isInterrupted()，不是!interrupted()—— 后者是静态方法，会清标志 - catch 里必须调一次
interrupt()，否则中断信号丢失，线程无法退出 - 如果
doWork()内部也调用了可中断方法（如Future.get()），要确保它抛出的InterruptedException被外层捕获并处理
为什么 ExecutorService.shutdownNow() 有时不生效
调用 shutdownNow() 后线程池返回了 List<runnable></runnable>，但你的任务还在跑，说明这些任务没响应中断。这不是线程池的问题，是你提交的任务本身没做中断检查。
shutdownNow() 的行为很明确：对每个正在运行的线程调用 interrupt()，然后把未开始的任务从队列中移出。它不管你的 Runnable 或 Callable 里写了什么。
- 如果你提交的是匿名内部类或 Lambda，且没在循环/递归/IO 等长耗时操作中检查中断，
interrupt()就只是设了个标志，什么都不会发生 - 使用
Future.cancel(true)也是同理：它只对Future对应的线程发interrupt()，不保证任务逻辑终止 - 特别注意
ReentrantLock.lock()不响应中断，要用lockInterruptibly()替代
中断状态被意外清除的典型场景
中断标志位非常脆弱，一不留神就被清掉，导致后续检查失效。最隐蔽的是 InterruptedException 抛出时自动清除，以及误用静态方法 Thread.interrupted()。
另一个高频陷阱是：在 finally 块里调用了会响应中断的阻塞方法（比如关流、释放锁），结果中断状态被吃掉，主线程以为任务已退出，其实它卡在 finally 里了。
- 永远优先用实例方法
thread.isInterrupted()查状态；仅在需要“检查+清除”原子操作时才用静态interrupted() - 不要在 finally 里调
Thread.sleep()、queue.put()这类可中断方法，除非你明确处理了其中断 - 如果任务封装成
FutureTask，记得重写done()方法，在这里检查isCancelled()并清理资源
