NIO SelectionKey处理：单/多线程选择及丢包、通道数疑问

我正在学习Selector多路复用多通道的I/O处理，看到大部分教程都用类似下面的代码依次处理SelectionKey：

Set<SelectionKey> selectedKeys = selector.selectedKeys();
Iterator<SelectionKey> iter = selectedKeys.iterator();
while (iter.hasNext()) {
    SelectionKey key = iter.next();
    if (key.isReadable()) {
        //processKey(key);
    }
    iter.remove();
}

我有个疑问：在处理某个Key（比如Key 1）的过程中，所有通道还在持续接收数据包：

Key 1 : [packet] [packet] [packet] [packet]
...
Key N : [packet] [packet] [packet] [packet]

如果处理Key 1的同时，所有通道都收到新数据包：

Key 1 : [packet] [packet] [packet] [newPacket]
...
Key N : [packet] [packet] [packet] [packet] [newPacket]

等到处理Key 2、Key 3的时候，会不会出现部分通道因为接收缓冲区满而丢包？比如：

Key 1 : [packet] [packet] [packet] [newPacket] [newPacket] {packet lost socket receive buffer full}
...
Key N : [packet] [packet] [packet] [packet] [newPacket] [newPacket] {packet lost socket receive buffer full}

另外还有两个问题：

• 是否应该把每个SelectionKey传入队列，用其他线程轮询实现多线程处理？
• 一个Selector可注册的最优通道数量是多少？

1. 单线程处理时会不会丢包？ #

丢包与否取决于传输协议和接收缓冲区的状态：

• TCP协议：TCP自带流量控制机制，当接收方缓冲区快满时，会通过TCP窗口通知发送方降低发送速率甚至暂停发送，只要不是缓冲区长期处于饱和状态，不会出现丢包。但如果单线程处理I/O的速度远慢于数据包到达速度，缓冲区持续溢出，TCP会触发重传，业务层面会出现明显延迟。
• UDP协议：UDP是无连接、无流量控制的协议，一旦接收缓冲区满，新到达的数据包会直接丢弃，这种情况下如果处理不及时，确实会发生丢包。

单线程处理SelectionKey的模式下，只要processKey里的I/O读取操作足够快，能及时清空接收缓冲区，就不会出现丢包问题。但如果processKey包含耗时的业务逻辑，会导致Selector无法及时处理后续就绪事件，缓冲区溢出的风险就会升高。

2. 是否需要用多线程队列处理SelectionKey？ #

不建议直接把SelectionKey丢给其他线程处理，因为NIO通道和Selector的操作并非线程安全——在非Selector线程调用通道的I/O方法，可能引发线程安全问题。

正确的做法是拆分I/O处理和业务处理：

• Selector线程只负责处理就绪事件的I/O操作（比如从通道读取数据到内存缓冲区），这个过程要尽可能快。
• 读取到的数据交给线程池（比如ThreadPoolExecutor）处理业务逻辑，这样Selector线程能快速回到select()循环，处理新的就绪事件，避免阻塞。

如果你的processKey只是简单的读取数据，单线程完全足够；只有当业务逻辑耗时较长时，才需要引入多线程处理业务部分。

3. Selector的最优通道注册数量 #

没有固定的“最优值”，主要取决于以下因素：

• 操作系统：Linux下的epoll模型可以轻松支撑几万甚至几十万的通道注册（epoll基于事件通知，而非轮询所有通道）；Windows旧版Selector用select模型，最多只能注册1024个通道（现在Windows NIO也支持IOCP，但和epoll仍有差异）。
• 业务场景：高并发低流量的场景（比如即时通讯的在线连接），一个Selector可以注册几万甚至更多通道；高流量场景（比如大文件传输），每个通道的I/O操作频繁，能支撑的通道数量会少很多，可能只有几千甚至几百。
• 硬件资源：CPU核心数、内存大小也会影响，更多核心可以配合多Selector线程（Reactor模式的多Reactor）来支撑更多通道。

实际应用中，建议根据自身业务场景做压测，找到最合适的通道数量；同时注意Selector的空轮询问题（Java 7及以上版本已优化），以及注册通道必须在Selector线程执行的规则。

内容的提问来源于stack exchange，提问作者chunkynuggy