多个Selector是高并发NIO横向扩展的关键，通过主从Reactor架构实现职责分离：main reactor专责ACCEPT，sub reactor分担READ/WRITE，避免单点瓶颈，支撑十万级连接。
多个 Selector 实例是实现高并发 NIO 服务横向扩展的关键手段，核心在于避免单个 Reactor 线程成为性能瓶颈。它不是简单地“多开几个 Selector”，而是通过职责分离与线程隔离，让连接接入、事件分发、I/O 处理各司其职，从而支撑万级甚至十万级并发连接。
为什么单个 Selector 会成为瓶颈
单 Reactor 单线程模型中，一个 Selector 要同时处理 accept、read、write、connect 四类事件，并在同一线程内完成所有事件的 dispatch 和 handler 调用。当连接数超过 5000，或某次业务逻辑（如反序列化、DB 查询）意外阻塞，整个 Selector 循环就会卡住——新连接无法 accept，已建立连接的 read/write 也会延迟响应。这不是 IO 性能问题，而是线程调度与事件处理耦合过紧导致的雪崩风险。
主从 Reactor 模型：分工明确的双层结构
主流方案采用 main reactor + sub reactor 架构：
- main reactor 仅负责监听 ServerSocketChannel 的 ACCEPT 事件，一旦有新连接到达，立即执行 accept() 获取 SocketChannel，然后将其轮询分配给某个 sub reactor（例如按 reactor 数组下标取模）
- sub reactor 各自持有独立的 Selector、线程和事件循环，只注册该 SocketChannel 的 OP_READ / OP_WRITE 事件，不处理 accept
- 每个 sub reactor 线程绑定固定数量的连接（如 2000–4000），避免单线程负载过重
- 连接建立后，其生命周期（读、写、关闭）完全由所属 sub reactor 全权管理，与 main reactor 解耦
Selector 实例数量如何设定
没有固定公式，但需结合硬件与场景权衡：
- sub reactor 数量通常设为 CPU 核心数 × 1～2（如 16 核服务器配 16 或 32 个 sub reactor）；过多会导致线程上下文切换开销上升
- 每个 Selector 上注册的 Channel 数建议控制在 3000 连接以内；可通过运行时监控 selectedKeys().size() 和 select() 平均耗时判断是否过载
- 若存在大量长连接+低频通信（如 IoT 心跳），可适当提高单 Selector 容量；若为短连接高频交互（如 HTTP API），应倾向更多 reactor 实例以降低事件延迟
实际部署中的关键细节
光有多个 Selector 不够，还需配套机制保障稳定性：
- 连接分配必须无状态：main reactor 分配新连接时，不能依赖任何共享状态（如原子计数器易成热点），推荐使用 ThreadLocal 随机种子 + 数组轮询，或 Consistent Hash（适合动态扩缩容）
- 跨 reactor 通信需异步化：比如 sub reactor A 中的 Handler 需要调用 DB，不能直接阻塞等待，而应提交到业务线程池，结果通过 ChannelHandlerContext.writeAndFlush() 回写到原连接对应的 sub reactor
- 资源绑定要显式管理：每个 SocketChannel 的 ByteBuffer、解码器、业务上下文等，都应随连接归属 reactor 初始化，避免跨 reactor 引用导致内存泄漏或竞态
- 异常连接需快速隔离：当某个 sub reactor 中出现大量 OP_READ 超时或半包粘包错误，应触发熔断，临时拒绝新连接分配至该 reactor，待其恢复后再重新纳入调度
