java nio非阻塞服务端优雅断开需主动识别异常（read返回-1或ioexception）、原子化关闭（先cancel key再close channel）、迭代后remove key，并在init/register中用try-finally兜底清理。
Java NIO 非阻塞服务端要实现优雅的连接断开与异常通道清理，关键不在“断开动作”本身，而在于**主动识别、及时释放、避免泄漏、不干扰主循环**。它不是等连接自然关闭，而是靠状态判断 + 显式关闭 + 选择器同步清理三步闭环。
连接断开的主动识别与响应
客户端静默断开（如直接关进程、网络中断）不会触发 OP_READ，但会表现为后续 read() 返回 -1 或抛出 IOException（如 Connection reset）。必须在读事件处理中捕获这些信号：
- 调用 channel.read(buffer) 后，若返回 -1，说明对端已正常关闭（FIN），应立即关闭该 channel
- 若 read() 抛出 IOException（如 ClosedChannelException、IOException with “Broken pipe” or “Connection reset”），说明连接异常中断，需立即清理
- 不要依赖 OP_READ 持续触发——空闲连接可能长期无数据，但 channel 仍有效；也不要轮询 isConnected()，它无法反映真实网络状态
异常通道的干净关闭流程
单个 channel 关闭必须原子化执行：释放资源 → 取消 key → 清理 buffer → 关闭 channel。顺序错误会导致 Selector 状态不一致或资源泄漏：
- 先调用 key.cancel()，从 Selector 中移除监听关系（这是最优先动作）
- 再调用 channel.close()，释放底层 Socket 和系统句柄
- 如果使用了 DirectByteBuffer，无需手动释放（JVM 自动回收），但避免在 handler 中长期持有 buffer 引用
- 注意：不能在 selector.select() 循环内部直接 close channel，应标记待清理，退出迭代后再统一 close（否则可能引发 ClosedChannelException 中断 select）
Selector 中已失效 Key 的安全清理
SelectionKey 在 cancel() 后不会立刻从 selectedKeys() 中消失，必须显式 remove()，否则下次 select() 仍可能遍历到已取消的 key，导致空指针或非法状态：
- 每次处理完一个 key 后，务必调用 iterator.remove()（不是 keys.remove(key)）
- 若在处理中发生异常，也要确保 finally 块里执行 iterator.remove()，防止 key 积压
- 定期调用 selector.selectNow() + 清理 cancelledKeys()（可选），但日常只需保证每次迭代后 remove 即可
初始化失败与半开连接的兜底防护
服务器启动或 accept 过程中出错时，容易遗留未注册或部分初始化的 channel，必须统一收口：
- accept() 成功后若 clientChannel.configureBlocking(false) 失败，必须立即 close() 并 cancel 对应 key
- register() 到 selector 前发生异常（如 OutOfMemoryError），需确保 serverChannel 和 selector 资源可安全释放
- Hutool 等成熟封装已内置 close() 清理链，自研实现建议在 init() 和 register() 周围加 try-finally，确保任意分支都能释放已分配资源
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
