怎么通过 SelectableChannel 的非阻塞模式理解 Java NIO 处理万级并发连接的底层事件驱动

先说说几个核心判断：Ja va NIO能支撑万级并发，核心并不是“用了Selector”这么简单。真正决定NIO高性能上限的，其实是非阻塞模式——如果这一步没做对，后面的事件驱动模型根本就运行不起来。

非阻塞是注册到Selector的硬性门槛

问题根源在于：非阻塞是注册到Selector的硬性前提。ServerSocketChannel、SocketChannel、DatagramChannel都继承自SelectableChannel，但默认全都是阻塞模式。open()之后如果不调用configureBlocking(false)，直接执行register()就会抛出IllegalBlockingModeException。这还真不是Ja va层面的任性设计——

• Linux的epoll、macOS的kqueue，这些操作系统级的多路复用机制，只能监听非阻塞的文件描述符
• 就算是侥幸把阻塞通道注册上去，select()不报错，后续的read()/write()也有可能把整个事件循环线程卡死
• FileChannel不能注册的原因也在这儿——它压根就不支持非阻塞I/O，也不继承SelectableChannel

事件驱动的本质是“状态变化通知”，不是轮询忙等

Selector本身并不“干”活儿，它只是把多个通道的就绪状态聚合起来。真正驱动逻辑的，是通道自身状态的切换过程：

• ServerSocketChannel收到SYN包 → 内核标记“可accept” → Selector返回OP_ACCEPT
• SocketChannel收到TCP数据包 → 内核缓冲区有数据 → 标记“可read” → Selector返回OP_READ
• SocketChannel发送缓冲区腾出空间 → 标记“可write” → Selector返回OP_WRITE（这个要注意，容易踩坑）

整个过程中，线程不需要等待I/O完成，只有在状态真正就绪的时候才会介入处理。这才是NIO能扛住万级并发的底层逻辑。

OP_READ和OP_WRITE的注册，必须动态调整

静态注册很容易引发性能陷阱。举个例子：一上来就同时注册OP_READ | OP_WRITE，会导致select()频繁返回，但实际既没有数据可读、也没有空间可写——这就是所谓的“虚假就绪”。正确的做法应该这样：

• 新accept进来的SocketChannel，只注册OP_READ（客户端大概率是率先发请求的）
• 当write()返回0，说明内核发送缓冲区满了，这时候再临时追加OP_WRITE
• 一旦写出部分数据，立刻取消OP_WRITE，避免持续唤醒线程
• OP_WRITE永远不应该长期保留在interestOps里

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

Selector返回的selectedKeys()是一个由其内部管理的Set，每次select()返回的是“新增就绪”的key列表，但系统不会自动清理。如果漏掉了keyIterator.remove()：

• 同一个key会在下一轮select()后重复出现，导致重复accept、重复read
• 如果多线程误操作selector，还可能触发ConcurrentModificationException
• 不能用for-each遍历selectedKeys()——因为它隐式创建了iterator却没法调用remove()

所以，一定要用显式的Iterator，在处理完每个key后立即调用remove()，这才是规范的写法。