interrupt() 不能直接唤醒阻塞线程，而是协作式中断：对 wait()/sleep()/join() 线程触发 InterruptedException 并清空中断状态；对 park() 仅返回且保持中断状态；对运行中线程仅设标志位。
Java 中不能直接用 interrupt() “唤醒”处于 wait()、join() 或 sleep() 等阻塞状态的线程，但可以触发它们提前退出等待，并抛出 InterruptedException —— 这是 Java 设计的协作式中断机制，本质是“通知线程：有人希望你停止等待，请尽快处理并退出”。
interrupt() 对不同等待状态的作用
调用线程的 interrupt() 方法后：
-
对
wait()（含wait(long)）状态的线程：线程会立即从等待中返回，并抛出InterruptedException；同时，该线程的中断状态被清空（即isInterrupted()变为false）。 -
对
sleep(long)或join()状态的线程：同样立即返回，抛出InterruptedException，中断状态也被清空。 -
对
LockSupport.park()：不会抛异常，但会立即返回；中断状态保持为true（需手动检查Thread.interrupted()或isInterrupted()）。 -
对已运行但未阻塞的线程：仅设置中断标志位（
isInterrupted() == true），不产生其他效果，需线程自行轮询判断。
正确响应 interrupt 的典型写法
关键不是“靠 interrupt 唤醒”，而是线程要主动捕获 InterruptedException 并合理退出。常见模式如下：
✅ 推荐写法（在 catch 中恢复中断状态或直接 return）：
JavaStoryDevelop
下载
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
立即学习“Java免费学习笔记（深入）”；
public void run() {
while (!Thread.currentThread().isInterrupted()) {
try {
// 可能阻塞的操作
Thread.sleep(1000);
} catch (InterruptedException e) {
// 中断发生：清理资源，然后退出循环
System.out.println("被中断，准备退出");
Thread.currentThread().interrupt(); // 恢复中断状态（可选，若上层需感知）
return; // 或 break;
}
}
}
为什么不能直接“唤醒” wait()？要注意锁和 notify 的配合
wait() 必须在同步块中调用，且依赖对象监视器。仅调用 interrupt() 虽能打断等待，但不会释放锁，也不会替代 notify()/notifyAll() 的语义。例如：
synchronized (obj) {
try {
obj.wait();
} catch (InterruptedException e) {
// 此时线程已退出 wait，但仍在 synchronized 块内，仍持有 obj 锁
System.out.println("中断了，但锁还在");
}
}
所以，如果期望线程在等待条件满足时被唤醒，仍应使用 notify() 配合条件变量；interrupt() 是用于“取消等待”的应急手段，比如超时、任务被取消等场景。
实际调试建议
- 永远不要忽略
InterruptedException（即不要空 catch 或只打日志）；它代表外部请求终止，应作为退出信号处理。 - 在捕获异常后，若需继续传播中断，调用
Thread.currentThread().interrupt()；若自己负责终止，则可直接退出。 - 避免在持有锁期间长时间 sleep/wait，否则可能阻碍其他线程获取锁。
- 使用
java.util.concurrent工具类（如CountDownLatch、Semaphore、BlockingQueue）时，它们的阻塞方法也都响应interrupt()，行为与wait/sleep/join一致。
