op_read触发但read()返回-1是因为tcp全双工特性：对端发送fin后，本端接收缓冲区状态变为“可读但无有效字节”，selector据此就绪，read()返回-1表示eof，需立即close channel、cancel key并清理上下文。
当 Java NIO 的 Selector 检测到某个 SocketChannel 返回 OP_READ，但实际读取时返回 -1（即 EOF），这表示对端已正常关闭连接（TCP FIN），此时应立即关闭本地 channel 并取消其在 selector 上的注册。
为什么 OP_READ 会触发但 read() 返回 -1？
这是因为 TCP 是全双工协议。对端调用 close() 或 shutdownOutput() 后，会发送 FIN 包，本端 TCP 栈将其视为“有数据可读”——即输入流已到达末尾。Selector 感知到 socket 接收缓冲区状态变化（从空变为“可读但无有效字节”），于是唤醒并报告 OP_READ 就绪。此时调用 channel.read(buffer) 会返回 -1，是标准的流结束信号。
正确捕获和处理 EOF 的步骤
在 SelectionKey.OP_READ 分支中，必须检查 read() 的返回值：
- 若返回 > 0：正常读取到数据，按业务逻辑处理
- 若返回 = 0：非阻塞模式下暂无数据（不常见于已就绪 key，可忽略或重试）
- 若返回 = -1：对端已关闭连接，应执行清理
典型清理操作（必须做）
发现 read() == -1 后，需同步完成以下动作：
- 调用
channel.close()关闭通道（自动释放底层 socket） - 调用
key.cancel()取消该 key 的注册（防止后续误处理） - 从管理结构（如
Map<socketchannel ...></socketchannel>）中移除该 channel 相关上下文 - 如有写队列，可丢弃未发送数据（除非要求优雅重发）
常见错误与注意事项
避免以下误区：
- 仅判断
isReadable()就直接读取，却不检查read()返回值 —— 会导致无限循环或 NPE - 读到
-1后只关闭 channel，却忘记key.cancel()—— 下次 select 可能再次返回该已失效 key（尤其在未设置OP_READ之外的 interestOps 时） - 在多线程环境下并发修改 key 的 interestOps 或调用 cancel，需确保线程安全（通常在 selector 线程内统一处理）
- 不要依赖
channel.isOpen()或channel.isConnected()判断是否断连 —— 它们在 FIN 后仍返回 true，只有read()返回 -1 才是可靠依据
不复杂但容易忽略：EOF 处理不是异常场景，而是 TCP 连接生命周期的自然终点，应作为常规分支对待。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
