主从 Reactor 架构通过 Boss 线程专管 ACCEPT、Worker 线程专管 READ/WRITE 实现多核高效利用；Worker 数量匹配 CPU 核心数，单 Selector 控制 2000–4000 连接，无锁轮询分配连接，业务逻辑须异步化。

核心思路是让每个 cpu 核心“专管一批连接”，而不是让一个 selector 独自扛下所有通道。这靠的不是多开几个 selector，而是用主从 reactor 架构把接入、分发、处理彻底拆开。

主从 Reactor 分工必须明确

单个线程+单个 Selector 无法压满多核，因为 ACCEPT 和 READ/WRITE 混在一起，一卡全卡。正确做法是：

• 启动一个 Boss 线程（main reactor），只注册 ServerSocketChannel，只监听 OP_ACCEPT
• 准备一组 Worker 线程（sub reactor），每个线程持有一个独立 Selector 和事件循环
• Boss 接收到新连接后，立即调用 accept() 得到 SocketChannel，再轮询分配给某个 Worker（比如下标取模）
• 该 SocketChannel 后续所有 OP_READ / OP_WRITE 都由所属 Worker 全权处理，不再跨线程

Selector 实例数量要匹配硬件能力

不是越多越好，关键看 CPU 核心数和连接活跃度：

• Worker 数量通常设为 CPU 逻辑核心数（如 16 核配 16 个），最多不超过核心数 × 2
• 每个 Selector 上注册的 Channel 控制在 2000–4000 个以内；可通过监控 selectedKeys().size() 和 select() 平均耗时判断是否过载
• 若连接多为长连接+低频心跳（如 IoT 场景），可适当放宽单 Selector 容量
• 若为短连接高频交互（如 HTTP API），应倾向更多 Worker，降低单次事件延迟

连接分配必须无状态且低开销

Boss 线程不能依赖共享变量做负载统计，否则会成为热点瓶颈：

• 避免使用 AtomicInteger.incrementAndGet() 做轮询计数——高并发下 CAS 失败率飙升
• 推荐用 ThreadLocalRandom 或预计算下标数组（如 int[] reactors = {0,1,2,3}）做无锁轮询
• 分配动作必须在 Boss 线程内完成，不可异步投递；SocketChannel 注册到目标 Worker 的 Selector 必须在对应线程内执行（可用 wakeup() + 队列通知）

实际编码中几个关键细节

光有多个 Selector 不等于负载均衡生效，配套机制缺一不可：

• 所有 Channel 必须 configureBlocking(false)，否则无法注册到 Selector
• 每个 Worker 的 Selector 循环里，必须手动调用 keyIterator.remove()，否则已处理 key 会持续堆积
• 业务逻辑不能阻塞 Worker 线程；耗时操作（如 DB 查询、JSON 解析）需提交到业务线程池
• 连接关闭必须由所属 Worker 触发 deregister + close，禁止跨 reactor 操作 Channel