NIO 选择器的取消操作：解析 SelectionKey.cancel() 延迟注销机制对系统句柄回收的影响-Java面试题-PHP中文网

selectionkey.cancel() 不会立即释放文件句柄，而是标记为待取消并加入 cancelledkeys 集合，待下次 select() 结束时统一清理，以保障线程安全和事件一致性。

nio 选择器的取消操作：解析 selectionkey.cancel() 延迟注销机制对系统句柄回收的影响

SelectionKey.cancel() 并不会立即从操作系统层面注销通道，而是将该键标记为“待取消”，放入 Selector.cancelledKeys() 集合中。真正的注销动作，要等到下一次 select() 调用结束时才执行。

这是 NIO 为保障线程安全和事件一致性所做的设计妥协：

Selector 的内部状态（如已就绪的键、兴趣集、就绪集合）在 select() 执行期间是被锁定或快照化的，不能在中途被并发修改
如果 cancel() 立即移除注册关系，可能导致正在处理的 SelectionKey 失效而未被察觉，引发 CancelledKeyException
延迟注销让 select() 能完整处理本次轮询周期内的所有就绪事件，再统一清理无效键

若不主动干预，cancelledKeys 长期堆积会阻碍底层文件句柄（socket fd）及时回收：

Channel 本身虽已 close()，但只要其 SelectionKey 还在 cancelledKeys 中未被处理，JVM 就不会触发底层 close(fd) 系统调用
尤其在高频断连场景（如心跳超时、客户端闪退），大量已 cancel 却未 select 的键会持续占用系统 fd 资源
Linux 默认单进程限制约 1024 个 fd，fd 耗尽后新连接将直接失败（IOException: Too many open files）

关键不是避免 cancel()，而是配合 select() 周期主动驱逐 cancelledKeys：

每次 select() 后显式调用 selector.selectNow() 或 selector.select(0) 一次，强制触发 cancelledKeys 清理（即使无就绪事件）
在业务逻辑中，关闭连接时务必按顺序执行：key.cancel() → channel.close() → 显式触发一次 select()
避免在 select() 阻塞期间长时间不唤醒——比如设置过长的超时（如 5s+）且无外部唤醒机制，会显著拉长注销延迟
可定期检查 selector.keys().size() 和 selector.cancelledKeys().size()，当 cancelledKeys 占比超过 20%，说明清理滞后，需优化 select 频率或连接生命周期管理

错误写法（句柄泄漏高发）：

key.cancel();
channel.close(); // 此时 fd 仍被持有
// 忘记调用 select()，且 selector 长时间阻塞在 select(1000) 中...

正确写法（句柄可控）：

key.cancel();
channel.close();
// 主动唤醒并清理
selector.wakeup(); // 中断阻塞
int selected = selector.selectNow(); // 立即执行注销
// 或至少保证下一轮 select 在毫秒级内发生