Java NIO Selector 模式实现高并发轮询详解

Java NIO 的 Selector 通过深度绑定操作系统内核的 I/O 多路复用机制（如 Linux epoll），以“事件驱动+内核通知”取代传统线程轮询，实现单线程高效管理成千上万个非阻塞 Channel——它不遍历所有连接，只响应内核精准推送的就绪事件，将时间复杂度从 O(N) 骤降至 O(K)（K 为实际活跃连接数）；但真正发挥其威力需严守关键实践：注册前必须设为非阻塞并明确指定 interestOps，迭代 selectedKeys 后务必手动 remove 避免重复处理，同时将耗时业务逻辑剥离出 IO 线程交由线程池执行，辅以堆外内存池与 GC 优化，才能在支撑海量连接的同时保障低延迟与高吞吐。

Selector 是怎么轮询成千上万个 Channel 的

它不靠线程遍历，而是依赖操作系统内核的 I/O 多路复用机制（Linux 上是 epoll，Windows 上是 IOCP 封装）。Selector.select() 调用会阻塞，直到至少一个注册的 Channel 就绪（比如有数据可读、可写、连接完成），这时内核把就绪列表返回给 JVM，Selector.selectedKeys() 返回的就是这批活跃事件的集合——你只处理真正需要响应的连接，而不是每毫秒扫一遍十万条连接。

关键点在于：就绪通知由内核触发，不是 Java 主动轮询；一次 select() 可能唤醒多个 Channel，但你只迭代 selectedKeys() 里那几十或几百个，复杂度从 O(N) 降到 O(1)～O(K)，K 是就绪数。

注册 Channel 时必须禁用阻塞模式并显式关注事件

SocketChannel 默认是阻塞的，直接注册到 Selector 会抛 IllegalBlockingModeException。而且，不指定 interestSet 就等于没注册任何事件，这个 Channel 永远不会出现在 selectedKeys() 中。

• 必须先调用 channel.configureBlocking(false)
• 再用 channel.register(selector, SelectionKey.OP_READ) 注册，不能漏掉第二个参数
• 如果后续要写数据，别在 OP_READ 事件里直接 channel.write()——可能写不完，得改用 key.interestOps(SelectionKey.OP_WRITE) 并确保 OP_WRITE 可用（注意：epoll 中 OP_WRITE 就绪条件很宽松，几乎总是就绪，慎用）

selectedKeys() 迭代后必须手动 remove，否则下次 select 会重复触发

Selector 内部用一个 SelectedSelectionKeySet 缓存就绪 key，每次 select() 返回前会把新就绪的 key 加进去，但不会自动清理已处理的 key。如果你只遍历不 remove()，同一个 key 会在下一轮 select() 后再次出现，导致重复处理甚至死循环。

正确做法是用迭代器边遍历边删：

Iterator<SelectionKey> iter = selector.selectedKeys().iterator();
while (iter.hasNext()) {
    SelectionKey key = iter.next();
    iter.remove(); // 必须这一步
    if (key.isReadable()) handleRead(key);
    if (key.isWritable()) handleWrite(key);
}

十万连接下 Selector 自身的性能瓶颈和规避点

单个 Selector 在 Linux 上用 epoll 实现，理论支持百万级连接，但实际卡在三个地方：JVM 堆内存（每个 SelectionKey 约 100+ 字节）、GC 压力（频繁创建/销毁 key）、以及单线程处理逻辑的 CPU 占用。当业务逻辑稍重（比如 JSON 解析、DB 查询），单线程立刻成为瓶颈，连接数上不去。

• 避免在 select() 循环里做耗时操作；IO 事件只做 read/write，业务逻辑扔给线程池
• 用 ByteBuffer 池（如 Netty 的 PooledByteBufAllocator）减少 GC
• 不要为每个连接 new 一个 Thread，但可以按需分发到固定线程池——这不是违背单线程 IO 模型，而是 IO 线程只管调度，不干重活
• 注意 Selector.wakeup() 频繁调用会导致 select() 提前返回，增加空转，仅在外部线程需中断阻塞时谨慎使用

真正难的不是撑住十万连接，而是让这十万连接持续低延迟收发——大部分坑藏在业务逻辑的同步阻塞和堆外内存管理里，而不是 Selector 本身。

到这里，我们也就讲完了《Java NIO Selector 模式实现高并发轮询详解》的内容了。个人认为，基础知识的学习和巩固，是为了更好的将其运用到项目中，欢迎关注golang学习网公众号，带你了解更多关于的知识点！