Java NIO中关闭Channel和Selector需严格遵循“判空→判isOpen()→捕获异常”三步法，按依赖顺序关闭（先Channel→再SelectionKey→最后Selector），以read()返回-1为唯一可靠关闭信号，避免资源泄漏与异常掩盖。
Java NIO 中关闭 Channel 和 Selector 不是调用一次 close() 就完事，关键在顺序、判空、异常处理和依赖关系。错一步就可能泄漏文件描述符、掩盖原始异常，或导致 ClosedChannelException。
Channel 关闭必须三步走
直接 channel.close() 在 finally 块里非常危险——它可能为 null，可能已被其他逻辑关闭，也可能抛出 IOException 打断主流程。
- 先判断
channel != null - 再确认
channel.isOpen()（注意：isOpen()只表示 Java 对象未显式关闭，不反映网络真实状态） - 最后调用
close()，并捕获IOException静默记录，不向上抛
推荐封装工具方法：
public static void closeQuietly(Channel channel) {
if (channel != null && channel.isOpen()) {
try {
channel.close();
} catch (IOException e) {
log.warn("Failed to close channel", e);
}
}
}
多个 Channel 要按依赖顺序关闭
典型场景如一个 SocketChannel 注册在 Selector 上，还关联着 SelectionKey。它们有明确的生命周期依赖：
立即学习“Java免费学习笔记（深入）”；
- 先关闭具体通道（如
SocketChannel），它会自动取消注册的key - 再显式调用
key.cancel()（如果尚未自动取消，或需提前清理） - 最后关闭
Selector—— 它内部持有多路复用资源（如 Linux 的 epoll 实例），不关会泄漏
每一步都应套用上述“判空→判 open→捕获异常”三步法，不能跳过。
read() 返回 -1 是关闭连接的唯一可靠信号
在事件循环中处理 OP_READ 时，channel.read(buffer) 的返回值决定后续动作：
- 返回 -1：对端已发送 FIN，TCP 连接逻辑关闭 → 必须立即执行 clean close（关闭 channel、cancel key、置空 buffer 引用）
- 返回 0：接收缓冲区为空，但连接正常 → 不可关闭，也不该重试，保持
OP_READ注册即可 - 抛出 IOException（如 “Connection reset”）：属于异常断连 → 同样执行 clean close，只是日志级别建议设为 ERROR
不要依赖 channel.isOpen() 判断是否该关，也不要等超时或心跳失败才关——-1 就是 EOF 的 Java NIO 表达方式。
慎用 try-with-resources，注意作用域陷阱
虽然 Channel 实现 AutoCloseable，但要注意：
- 必须在 try 括号内直接初始化：
try (SocketChannel ch = SocketChannel.open()) { ... } - 避免先声明变量再赋值，否则外部引用可能导致重复关闭或提前关闭
- 若 Channel 来自连接池（如 Netty），不要手动
close()，应调用release()或对应回收方法
Selector 同理，不建议用 try-with-resources 管理，因其生命周期通常跨多个请求，更适合显式控制关闭时机。
