selector监控通道i/o就绪状态而非变量，需非阻塞通道注册并正确管理selectionkey：注册时设兴趣事件与attachment，select后用iterator遍历并remove已处理key，业务逻辑须交由线程池执行。

selector 本身不监控“变量”，它监控的是 通道（channel）的 i/o 就绪状态，比如是否有新连接到达、是否有数据可读、是否可以安全写入等。所谓“多通道变量就绪”，实际是指多个注册到 selector 上的非阻塞通道，在某次 select() 调用后，其对应的 selectionkey 进入就绪集合（selectedkeys()），表示该通道在指定事件上已准备就绪。

必须先确保通道是非阻塞模式

这是硬性前提，否则注册会直接失败：

• ServerSocketChannel、SocketChannel、DatagramChannel 都必须调用 configureBlocking(false)
• 阻塞通道调用 register() 会抛 IllegalBlockingModeException，程序中断
• 服务端监听通道通常只注册 OP_ACCEPT；客户端连上后，再注册 OP_READ（不是一上来就全注册）

注册时明确兴趣事件并合理使用 attachment

每个 register() 调用都会返回一个 SelectionKey，它是通道与 Selector 的绑定凭证：

• 注册示例：channel.register(selector, SelectionKey.OP_READ, myStateObj)
• attachment 可传任意对象（如自定义的连接上下文、缓冲区、协议解析器），避免用 Map 查状态，提升局部性
• 不要重复注册同一通道多次；若需变更兴趣集，应调用 key.interestOps(newOps)，而非重新 register
• 刚注册的通道不会立刻触发事件——比如新 accept 的 SocketChannel 注册 OP_READ 后，要等对端真正发数据才会被 select 唤醒

select 后必须遍历并手动移除已处理的 key

select() 返回后，selectedKeys() 是一个可变集合，不清理会导致重复处理或逻辑错乱：

• 务必用 Iterator 遍历，并在处理完每个 key 后调用 iterator.remove()
• 不能用增强 for 循环 + remove()，会抛 ConcurrentModificationException
• 如果某个 key 的事件没处理完（比如一次 read 没读尽所有数据），下次 select() 仍可能再次返回它——这是正常行为，不是 bug
• 若 key 对应的连接已关闭（如 read() 返回 -1），应立即调用 key.cancel() 并关闭 channel

区分真实就绪与伪就绪，避免空轮询和业务阻塞

就绪 ≠ 立刻能完成 I/O，更不等于可执行耗时逻辑：

• read() 返回 0：不是错误，可能是 TCP 窗口满或对方发了零长包；需结合协议判断是否消息收完
• read() 返回 -1：对端 FIN，必须关闭连接（key.cancel() + channel.close()）
• OP_WRITE 就绪通常意味着发送缓冲区有空间，但不代表一定能写满；写完后建议及时 key.interestOps(OP_READ)，否则会持续触发，造成 CPU 空转
• 所有业务逻辑（JSON 解析、DB 查询、HTTP 调用）必须剥离出 selector 线程，交给线程池异步执行；selector 线程只做字节收发和状态机跳转