必须手动移除SelectionKey，因为selectedKeys()是复用且不自动清理的集合；需在迭代中调用iter.remove()或key.cancel()，否则会导致重复事件、CPU飙升和连接异常。
SelectionKey 在处理完事件后必须从 selectedKeys() 集合中手动移除，否则下次 select() 返回时会重复触发同一事件——这不是 bug，而是 NIO 的设计机制：selectedKeys() 是一个复用的、非自动清理的集合，需开发者显式调用 iterator.remove() 或 key.cancel() 来清理。
为什么必须手动移除
Selector 内部使用一个简单的 Set（通常是 SelectedSelectionKeySet）缓存就绪的 key。它不会在每次事件处理后自动清空或移除已处理的 key，因为：
- 同一个 key 可能多次就绪（例如连续收到多段数据，OP_READ 持续就绪）；
- 是否“处理完成”由业务逻辑决定，Selector 无法判断你是否真正消费完数据；
- 避免同步开销，不自动 remove 是性能权衡的结果。
正确移除的两种方式
推荐始终在 Iterator 遍历过程中调用 remove()，这是线程安全且高效的做法：
✅ 推荐写法（遍历时 remove）：
Set<SelectionKey> selected = selector.selectedKeys();
Iterator<SelectionKey> iter = selected.iterator();
while (iter.hasNext()) {
SelectionKey key = iter.next();
iter.remove(); // 关键：必须调用！
if (key.isValid() && key.isReadable()) {
handleRead(key);
}
}
⚠️ 不推荐写法（遍历中直接 remove 集合）：
// 错误！会抛 ConcurrentModificationException
for (SelectionKey key : selector.selectedKeys()) {
selector.selectedKeys().remove(key); // ❌ 危险
}
遗漏移除的典型后果
若忘记 iter.remove()，会导致：
- 同个 key 在后续 select 调用中反复出现在 selectedKeys 中，造成重复处理（如反复读空缓冲区、重复 accept 同个 channel）；
- CPU 占用飙升（busy loop）；
- 连接假死或响应延迟（因无效 key 挤占迭代时间）；
- 某些 JDK 版本下可能引发
CancelledKeyException（如果 key 已被 cancel 但仍在集合中）。
进阶建议：结合 cancel 与清理
当连接关闭或发生异常时，应主动 cancel key 并确保其不再参与轮询：
- 调用
key.cancel()标记为取消，该 key 将在下一次select()时被清理出 keys 集合； - cancel 后仍需在本次迭代中
iter.remove()，否则当前轮次仍会残留； - 可在
finally块中统一清理，避免遗漏：
try {
if (key.isAcceptable()) handleAccept(key);
else if (key.isReadable()) handleRead(key);
} catch (IOException e) {
key.cancel();
closeChannel(key.channel());
} finally {
iter.remove(); // ✅ 确保移除，无论成功失败
} 
