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 线程只做字节收发和状态机跳转
