当Thread.interrupt()目标是一个在Selector.select()中阻塞的线程时，选择器会立即返回一个空的选择键集合，同时设置线程的中断标志。这就造成了架构上的模糊性，因为调用代码无法仅通过返回值判断通道是否准备好进行I/O，或者返回是否仅仅反映了中断信号。与Selector.wakeup()不同，后者在不影响中断状态的情况下解锁选择器，而中断则将关闭信号与I/O事件混淆。因此，健壮的实现必须显式检查Thread.interrupted()或咨询共享的volatile状态变量，以区分真实准备和虚假唤醒，从而防止占用CPU的自旋循环。
考虑一个高吞吐量的Java NIO网关处理市场数据源，其中一个专用线程在Selector.select()上阻塞，以将SelectionKey事件分发给工作线程。在零停机时间的部署过程中，编排层必须向该选择器线程发送信号，优雅地停止操作，完成正在进行的事务。
最初的实现利用Thread.interrupt()来发送终止信号。虽然这成功地解锁了select()，但它引发了一个关键的活锁：select()返回零个键，导致事件循环在满CPU利用率下持续迭代。线程假设存在I/O活动，尝试对所有注册的通道进行非阻塞读取，发现没有准备好，并立即重新调用select()，由于中断标志仍留存，select()迅速返回。
一个建议的替代方案用select(100)替代了无限阻塞，同时引入了一个volatile布尔关停标志。这一策略通过限制阻塞时间防止了CPU饱和，并在不依赖Thread.interrupt()的情况下，提供了一个简单的轮询机制用于终止信号。然而，它引入了高达超时持续时间的可预测延迟，以及在峰值负载下上下文切换开销增加了20%，从而降低了高频操作的吞吐量。
另一个候选解决方案使用Selector.wakeup()，仅通过关停钩子触发，完全避免了中断语义。这提供了瞬时解锁，而没有空键集合的模糊性，并且在真实紧急终止情况下保留了中断标志。然而，它在选择器线程处理键而非阻塞时，如果执行wakeup()，会存在“丢失唤醒”的竞争条件，可能导致select()无限阻塞，直到下一个I/O事件到达。
最终设计通过使用小心的happens-before语义，将Selector.wakeup()与volatile AtomicBoolean关停标志同步。关停序列原子性地设置标志，然后调用wakeup()，而事件循环在select()返回后立即检查该标志，如果请求终止则干净退出，而不考虑键的可用性。这消除了CPU自旋，直到关停开始保持了全I/O吞吐量，并且在不依赖中断状态检查的情况下达成了低于50毫秒的终止延迟。
在滚动部署过程中，网关成功处理了超过10,000个并发连接，并且没有失败的请求。关停序列中的CPU利用率保持在基准水平，架构提供了清晰的I/O事件处理与生命周期管理信号之间的分离。
Thread.interrupted()与Thread.isInterrupted()有何不同，清除标志为何在嵌套清理例程中造成危害？
Thread.interrupted()检查并清除当前线程的中断状态，而Thread.isInterrupted()探测标志而不做修改。在选择器循环中，开发者常常调用Thread.interrupted()来检测关停信号，目的是退出循环。然而，如果后续清理代码执行阻塞I/O操作，如channel.close()或等待CountDownLatch终止，这些操作将看不到先前清除的中断状态，可能会无限期阻塞，而不是响应原始的终止请求。
为什么Selector.select()在中断时正常返回零个键，而不是抛出InterruptedException，这造成了什么控制流模糊性？
与Object.wait()或Thread.sleep()等阻塞方法不同，Selector.select()没有声明InterruptedException，而是在调用Thread.interrupt()时立即返回零个选定键。这一设计选择将真实的I/O准备（偶然可能返回零个键）与中断信号混淆，迫使应用程序实现明确的状态检查，以区分“没有通道准备好”和“请求关停”。候选人常常忽视这一区别，在循环中假设零个键即表示活锁或立即重试，导致CPU饱和，而选择器仅仅是在响应中断标志。
Selector.wakeup()为何对于共享变量没有内存可见性保证，为什么这需要volatile或同步语义用于关停标志？
虽然Selector.wakeup()原子性地解锁选择器线程，但它并未在唤醒调用与被解锁线程随后的共享关停变量读取之间建立happens-before关系。因此，如果不将关停标志声明为volatile或在同步块内访问，选择器线程可能观察到过时的缓存值（假），即使在执行wakeup()后，导致它重新进入select()并无限期阻塞，尽管逻辑上的关停已经启动。这一微妙的Java内存模型交互意味着，单独的wakeup()不足以实现可靠的跨线程通信；必须与适当的同步配对，以确保状态变化的可见性。