在Java多线程编程中，中断机制是实现线程间协作与控制的关键技术，也是一个容易引发混淆和错误的领域。特别是Thread.interrupted()和isInterrupted()这两个方法，虽然名称相近，但其功能与使用场景却有本质区别。许多线程状态异常或逻辑错误的根源，往往在于对这两个方法的误用。
Thread.interrupted() 会清空中断标志，别误当 isInterrupted() 用
两者的核心差异在于行为模式。Thread.interrupted()是一个静态方法，用于检查当前正在执行的线程的中断状态。其关键特性在于，它执行的是一个“检查并清除”的原子操作——调用后，线程的中断标志位会立即被重置为false。
而thread.isInterrupted()是一个实例方法，它仅负责“读取”指定线程对象的中断标志位，不会对其进行任何修改。一个典型的误区是，开发者本想检查线程状态，却在后续逻辑中发现isInterrupted()返回了false，从而误判线程从未被中断。实际上，这很可能是由于之前调用了Thread.interrupted()，导致中断标志被悄无声息地清除了。
典型使用场景：循环中响应中断并退出
这个方法最经典的应用场景，是在需要长时间运行或包含阻塞操作的循环结构中。其目的是能够及时响应外部通过Thread.interrupt()方法发出的中断请求，从而实现任务的优雅终止。在这种情况下，必须使用Thread.interrupted()，否则中断逻辑极易出错。
- 标准的实践是，在每次循环迭代的开始处调用
Thread.interrupted()。这样做的好处是双重的：既能判断是否应该停止执行，又能确保旧的、已被处理过的中断标志不会对后续的判断逻辑造成干扰。 - 如果该方法返回
true，常见的处理策略是直接使用break跳出循环，或者主动抛出一个InterruptedException（请注意，这里抛出异常是主动终止逻辑的一种方式，并非指从sleep()等阻塞方法中被唤醒）。 - 需要特别警惕的是，不要在同一个循环逻辑中反复调用
Thread.interrupted()来“轮询”状态。因为第一次调用后标志位已被清除，后续调用几乎总是返回false，这会导致逻辑判断失效。
while (true) {
if (Thread.interrupted()) { // 检查并清空
break;
}
doWork();
}
和 sleep()/wait()/join() 配合时，优先捕获 InterruptedException
当线程正处于sleep()、wait()或join()这类可中断的阻塞状态时，处理方式有所不同。此时，外部调用interrupt()会立即唤醒线程，并抛出一个InterruptedException。关键点在于，JVM在抛出这个异常的同时，已经自动将线程的中断状态清除了。
因此，如果在catch代码块中再去调用Thread.interrupted()，它必定会返回false。这并不意味着中断没有发生，仅仅是因为标志位已经被系统清理过一次了。
- 正确的处理方式是：在捕获到
InterruptedException异常后，通常应立即恢复线程的中断状态，即调用Thread.currentThread().interrupt()。这样，上层的调用者或后续的代码才能感知到中断事件的发生。 - 错误的做法是：在
catch块中再次调用Thread.interrupted()进行判断——这毫无意义，结果总是false。 - 存在一种特殊情况：如果阻塞操作本身没有抛出异常（例如
Object.wait(long)因等待超时而正常返回），这时才需要手动使用Thread.interrupted()来检查中断是否在等待期间发生过。
重置中断状态不能靠 interrupted()，得用 currentThread().interrupt()
这里存在一个更隐蔽的“陷阱”。许多人下意识地认为，调用一次Thread.interrupted()就能“恢复”或“重置”中断状态。事实恰恰相反，它的作用是“清空”。如果你希望中断信号能够沿着调用链继续向上层传递，就必须显式地、手动地重新设置中断标志位。
- 举例来说，在
catch (InterruptedException e)之后，如果什么都不做就直接返回，那么这次中断信号就在当前代码层“丢失”了。 - 应该补充一行代码：
Thread.currentThread().interrupt();。这才是真正意义上的“重置”（更准确地说是“重新设置”）中断标志。 - 请注意，这个操作本身不会抛出异常，也不会中断当前正在执行的代码流，它只是为后续可能调用的
interrupted()或isInterrupted()方法提供一个判断依据。
总而言之，线程的中断状态是一个易失的、一次性的协作信号。Thread.interrupted()的“检查+清空”是一个不可分割的原子操作。真正的挑战不在于如何调用这个方法，而在于清晰地思考：在这次检查之后，中断信号是否还有继续存在的必要？如果答案是肯定的，那么立即调用currentThread().interrupt()进行补设，就是不可或缺的关键步骤。
