RST导致Selector持续返回OP_READ，是因为内核将异常关闭的socket标记为“可读”以通知应用层，而Selector仅检测就绪状态并不感知是否已处理；若代码未检查read()返回值或异常便循环select，就会陷入CPU 100%死循环。
Java NIO 的 Selector 在底层依赖操作系统 I/O 多路复用机制（如 Linux 的 epoll），而 TCP 连接被对端异常关闭（发送 RST）时，内核会将该 socket 标记为“可读”，但实际读取时会立即返回 -1（流结束）或抛出 IOException（如 `Connection reset`）。若业务代码未正确处理这类“伪就绪”，就可能在 select() 返回 OP_READ 后反复尝试读取、又立即触发就绪、再读取……陷入 CPU 100% 的死循环。
为什么 RST 会导致 Selector 持续返回 OP_READ
当对端发送 RST，本端 socket 的接收缓冲区虽为空，但内核会将其状态设为“有数据可读”——因为 TCP 协议栈需要通知应用层：连接已异常终止。此时调用 channel.read() 通常会：
- 返回 -1（表示对端正常关闭，即 FIN）；
- 或抛出
IOException，消息含"Connection reset"或"Broken pipe"； - 极少数情况下返回 0（取决于系统和 JDK 版本），但 socket 实际已不可用。
关键点在于：Selector 不感知应用层是否真正处理了这个事件。只要 socket 的内核读就绪标志仍被置位（且未被清除），下次 select() 就还会报告 OP_READ。
标准做法：读操作后必须检查返回值并清理通道
每次从 SelectionKey 获取到 OP_READ 就绪后，务必执行完整读取逻辑，并根据结果决定是否取消键或关闭通道：
立即学习“Java免费学习笔记（深入）”；
- 若
read(buffer)返回 -1 → 对端已关闭（FIN），应key.cancel()+channel.close()； - 若抛出
IOException且 cause 是 RST（如e.getMessage().contains("reset")）→ 同样取消 key 并关闭 channel； - 若返回 0 → 不代表错误，但需注意：某些旧版 JDK 在 RST 后可能短暂返回 0，建议结合超时或二次探测判断，稳妥起见仍建议关闭；
- 切勿只调用
read()而不检查返回值或异常，也别在 catch 块里简单吞掉异常后继续循环。
增强健壮性：注册前设置 SO_KEEPALIVE 或应用层心跳
仅靠被动捕获 RST 有延迟（尤其空闲连接）。主动预防更可靠：
- 创建
SocketChannel后启用 keepalive：channel.socket().setKeepAlive(true)，让内核定期探测对端存活； - 在业务层实现轻量心跳（如固定间隔发 PING/PONG），超时无响应则主动断连；
- 对长时间无读写活动的连接，服务端可设置空闲超时（如用
SelectionKey.attach()记录最后活跃时间），定时扫描清理。
调试技巧：确认是否真因 RST 导致死循环
遇到疑似死循环时，快速定位方法：
- 在 OP_READ 分支开头加日志：
log.debug("OP_READ for key: {}", key);； - 紧接其后打印读取前的 socket 状态：
log.debug("isConnected={}, isClosed={}, isInputShutdown={}", ch.isOpen(), ch.isRegistered(), ch.socket().isInputShutdown());； - 捕获所有
IOException并打印完整堆栈，重点看是否重复出现java.io.IOException: Connection reset by peer； - 使用
strace -e trace=epoll_wait,read,close -p <pid>观察系统调用行为，确认是否 epoll_wait 不断返回同一 fd 的 EPOLLIN。
不复杂但容易忽略：RST 不是 bug，而是网络常态；Selector 的职责只是通知“可读”，解读语义和善后永远是你的代码责任。
