Java NIO中客户端断连清理唯一可靠依据是read()返回-1，须在selector线程原子性执行channel.close()、key.cancel()及上下文清除；异常IOException也需统一执行相同清理流程。
Java NIO 中处理客户端断开连接后的资源清理，关键在于准确识别断连信号并同步完成通道关闭、键注销与上下文清除三步动作。不能依赖连接状态方法（如 isOpen() 或 isConnected()），唯一可靠依据是 read() 返回 -1。
捕获 EOF：只看 read() 返回值
当 SocketChannel.read(buffer) 返回 -1，说明对端已发送 FIN，TCP 连接进入逻辑关闭状态。这是唯一可信的断连标志：
- 返回
> 0：正常读到数据，按业务解析 - 返回
0：接收缓冲区为空，连接仍有效，保持OP_READ注册，不取消 key，不重试读 - 返回
-1：必须立即执行清理流程
标准清理动作（缺一不可）
发现 read() == -1 后，需在 selector 线程内原子性完成以下操作：
- 调用
channel.close()—— 关闭底层 socket，释放文件描述符 - 调用
key.cancel()—— 从 selector 中移除该 key，防止下次select()再次就绪 - 从管理容器中移除关联上下文 —— 如
Map<SocketChannel, Session>、心跳定时任务、写队列等 - 显式置空引用（可选但推荐）—— 将 channel、buffer、key 等设为
null，避免后续误用
常见陷阱与规避方式
很多问题源于对 TCP 协议和 NIO 行为的理解偏差：
立即学习“Java免费学习笔记（深入）”；
- 误判
isReadable()就等于有数据可读：必须读完再判断返回值，否则可能陷入空轮询 - 只关 channel 不 cancel key：失效 key 可能持续触发
OP_READ，造成 CPU 占用飙升 - 在非 selector 线程并发修改 key：interestOps 或调用 cancel 必须在 selector 所在线程执行，或加锁同步
- 用
buffer.clear()替代compact()：若还有未读完的半包，clear()会丢弃残留数据，导致协议解析失败
补充：异常中断也要统一收口
除 read() == -1 外，read() 或 write() 抛出 IOException（如 Connection reset、Broken pipe）也代表连接异常终止。此时同样应执行与 EOF 相同的清理动作：
- 关闭 channel
- 取消 key
- 清理上下文
- 记录日志或上报监控（建议传入错误码、堆栈摘要）
