高效java nio线程模型核心是职责分离：主从reactor分工处理accept与io，业务逻辑剥离至独立线程池，selector与buffer精细管理，杜绝阻塞操作和伪nio反模式。
高效设计 Java NIO 线程模型，核心不是“多线程”本身，而是把不同性质的任务分到合适的线程上，避免阻塞 IO 线程、防止业务拖垮事件循环、减少上下文切换。关键在于职责分离和资源可控。
用主从 Reactor 分离连接与 IO 处理
Accept（建连）和 Read/Write（数据收发）应由不同线程组承担：
- 主线程（Main Reactor）只做一件事：监听 ServerSocketChannel 的 OP_ACCEPT 事件，接受新连接，然后把新建的 SocketChannel 轮询分发给某个 Sub Reactor
- 子线程组（Sub Reactor）每个持有一个 Selector，负责注册该连接后续的所有读写事件；它们不处理业务逻辑，只做数据搬运（读到 ByteBuffer、触发回调、写回响应）
- 这样既避免了单 Reactor 的 CPU 核心闲置，又防止 Accept 阻塞在大量并发连接接入时影响 IO 调度
业务逻辑必须剥离出 Reactor 线程
Reactor 线程只做轻量级 IO 事件分发，所有耗时操作（如数据库查询、JSON 解析、远程调用）必须交给业务线程池：
- Handler 在收到完整请求后，不应直接执行业务，而是封装成 Runnable 或 CompletableFuture 提交到独立线程池
- 响应写回仍需回到对应 Sub Reactor 线程（因为 write 操作要操作 Channel 和 SelectionKey），所以业务线程完成后再通过任务队列或唤醒机制通知 Reactor 线程发起 write
- 线程池大小建议设为 CPU 核数 × 1.5～2，避免过度创建线程导致上下文开销反超收益
Selector 和 Buffer 要精细管理
线程模型再好，底层细节失控也会拖垮性能：
- 每个 Sub Reactor 独占一个 Selector，不要多个线程共用同一个 Selector（JDK 不保证线程安全）
- 每次 select() 后必须 clear selectedKeys()，否则重复处理旧事件；取消 key 前要先从 selectedKeys 中移除，再调用 cancel()
- 使用 DirectBuffer 处理网络数据，减少堆内拷贝；但注意它的分配/回收成本，可配合对象池复用 ByteBuffer
- 手动处理粘包/半包——Reactor 只管“有数据可读”，不代表一条完整消息已到达，需在 Handler 中维护读状态（比如按长度头或分隔符切分）
避免常见反模式
这些做法看似简单，实际会严重削弱 NIO 优势：
- 在 Reactor 线程里调用阻塞 API（如 JDBC 查询、Thread.sleep、File.read）——直接卡死整个事件循环
- 为每个连接创建新线程去 handle（即伪 NIO，本质还是 BIO 思维）——失去多路复用意义，内存和线程数照样爆炸
- Selector.select() 超时设为 0（忙轮询）或过大（延迟升高）——合理值通常为 100～1000ms，兼顾响应与 CPU 占用
- 忽略 OP_WRITE 注册时机——仅当 write 返回 0（缓冲区满）时才注册 OP_WRITE，处理完立即取消，否则持续被唤醒浪费 CPU
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
