configureblocking(false) 是不可跳过的首要步骤，因操作系统多路复用机制（如epoll、kqueue）仅支持非阻塞文件描述符，阻塞模式下注册selector会直接抛illegalblockingmodeexception，且后续i/o可能卡死事件循环。

ServerSocketChannel 必须先调用 configureBlocking(false) 才能注册进 Selector，否则直接抛 IllegalBlockingModeException——这不是调试阶段才暴露的问题，是启动即失败的硬性门槛。

为什么 configureBlocking(false) 是不可跳过的第一步

操作系统级多路复用（Linux 的 epoll、macOS 的 kqueue）只作用于非阻塞文件描述符。ServerSocketChannel.open() 默认就是阻塞模式，不显式切换，后续所有注册、select()、甚至看似成功的 accept() 都可能在某次读写时突然卡住整个事件循环线程。

• DatagramChannel 和 SocketChannel 同理，包括 accept() 返回的新连接通道，也必须立刻设为非阻塞
• FileChannel 无法注册，因为它不是 SelectableChannel 子类，也不支持非阻塞 I/O
• 跳过这步去查“为什么 selector 不触发 OP_READ”，纯属方向错误——根本没注册成功

OP_ACCEPT、OP_READ、OP_WRITE 的注册时机不能写死

常见误操作是把 OP_READ 和 OP_WRITE 一起注册到刚 accept() 进来的 SocketChannel 上，结果 select() 频繁唤醒但无数据可读、也无空间可写，CPU 白白拉高。

• 新连接进来时，只注册 OP_ACCEPT（服务端）或 OP_READ（客户端已连上）
• 需要回包但 write() 返回 0（内核 TCP 缓冲区满），才临时追加 OP_WRITE
• 一旦写出部分数据，立刻用 key.interestOps(key.interestOps() & ~SelectionKey.OP_WRITE) 清掉它
• OP_CONNECT 只用于客户端主动建连，服务端网关完全用不到

selectedKeys() 遍历后必须手动 remove()

漏掉 keyIterator.remove() 不是“少写一行”，而是会导致同一 SelectionKey 在下次 select() 后重复出现在 selectedKeys() 集合里。

• 轻则逻辑错乱：比如对同一个连接反复执行 accept() 或多次读取同一段缓冲区
• 重则触发 ConcurrentModificationException：尤其当多个线程误操作了同一个 Selector
• 注意是 Iterator 的 remove()，不是 selectedKeys().remove() —— 后者会破坏集合结构

Selector 本身不是性能瓶颈，但缓冲区和事件节奏是

Selector 只是骨架。真正决定能否撑住万级并发的，是缓冲区怎么分配、事件处理是否及时、系统级多路复用器有没有被压垮。

• 避免每次 read() 都 new ByteBuffer；用池化（如 ThreadLocal 缓存或对象池）管理 ByteBuffer
• select() 调用不要带超时参数滥用——频繁轮询比合理阻塞更耗 CPU
• Linux 下确认 /proc/sys/net/core/somaxconn 和 ulimit -n 是否足够，否则连接还没进 Selector 就被内核丢弃
• 单线程模型下，任何阻塞操作（如日志同步刷盘、慢 SQL、未设超时的 DNS 查询）都会拖垮全部连接

关键点不在“怎么注册”，而在于“注册之后每一帧怎么收发、怎么清理、怎么让内核不等你”。很多问题表面是 Selector 不工作，实际是缓冲区没 flip、是 key 没 remove、是 write 后忘了取消 OP_WRITE——这些细节不抠清楚，换再新的 JDK 也没用。