thread.interrupted()是静态方法，仅检查并清除当前线程的中断状态；连续调用第二次几乎总返回false，易致中断丢失，应改用isinterrupted()或缓存结果。
Thread.interrupted() 是一个静态方法，它只作用于当前线程（即调用它的那个线程），并且**会清除当前线程的中断状态**——这是它最关键的副作用，也是最容易被误解的地方。
它只检查并清空“当前线程”的中断标志
不同于实例方法 isInterrupted()（不改变状态），interrupted() 是静态的，内部等价于：
- 读取当前线程的中断状态（boolean 值）
- 立即将该线程的中断状态重置为
false - 返回读取到的原始值
这意味着：连续两次调用 Thread.interrupted()（中间无其他线程干预），第二次几乎总是返回 false，除非在这之间又被中断了。
典型误用场景：在循环中重复判断却未意识到状态已被清空
比如下面这段常见但有问题的代码：
JavaStoryDevelop
下载
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
while (!Thread.interrupted()) {
doWork();
if (Thread.interrupted()) { // 这里永远进不去！因为上一轮循环末尾已清空状态
break;
}
}
正确写法应避免重复依赖 interrupted() 判断，或改用 isInterrupted()（需通过 Thread.currentThread() 调用）：
- 单次检查后保存结果：
if (Thread.interrupted()) { /* 处理中断 */ } - 需要多次判断时，用
Thread.currentThread().isInterrupted()（不重置） - 标准响应中断模式：在阻塞操作（如
sleep、wait、join）中捕获InterruptedException并主动退出
和 interrupt()、isInterrupted() 的对比要记牢
-
thread.interrupt()：对指定线程设置中断状态（可能触发异常或影响阻塞行为） -
thread.isInterrupted()：查询指定线程中断状态，不修改任何状态 -
Thread.interrupted()：只查当前线程，查完就清零
三者行为差异直接决定线程协作逻辑是否健壮。尤其在自定义取消逻辑、任务终止、超时控制中，混淆它们会导致中断信号丢失或重复响应。
实际调试建议：别只看返回值，要观察状态变化
若发现中断没生效，可临时加日志验证：
- 在关键位置打印
Thread.currentThread().isInterrupted()（保留状态） - 对比
Thread.interrupted()调用前后的结果 - 注意 JVM 层面：I/O 阻塞（如
FileInputStream.read()）通常不响应中断，而 NIO 的Channel或Selector可以
理解这个副作用不是为了炫技，而是让中断机制真正成为可控的协作信号，而不是隐蔽的 bug 来源。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
