Java NIO高并发服务器核心是用Selector事件驱动替代多线程，通过非阻塞Channel、状态Buffer和单例Selector实现高效连接管理；需正确初始化、注册OP_ACCEPT、循环select处理就绪事件、及时remove key、按协议解析粘包半包，并分离IO与业务线程。
Java NIO 多路复用高并发服务器的核心设计，不是堆线程，而是让少数线程高效驱动大量连接。关键在于用好 Selector 做事件分发中枢，配合非阻塞 Channel 和状态可控的 Buffer，形成“有事才干活”的响应式模型。
服务端启动与 Selector 初始化
先创建非阻塞的 ServerSocketChannel，绑定端口并配置为非阻塞模式；再打开一个 Selector，将该通道注册到 selector 上，关注 OP_ACCEPT 事件。这一步必须在注册前完成 configureBlocking(false)，否则会抛异常。
- Selector 实例应全局单例，避免重复创建开销
- 建议调用
Selector.open()后立即设置select()超时（如 1000ms），防止无限阻塞影响优雅关闭 - 注册时传入 attachment（比如自定义的 Handler 或上下文对象），方便后续事件处理时直接获取业务逻辑入口
事件循环与就绪处理
主循环中反复调用 selector.select()，它会阻塞直到至少一个注册通道就绪。返回后遍历 selectedKeys() 集合，逐个判断事件类型并处理：
Java注释规范Skills
下载
当用户要求为 Java 代码添加注释、修改注释、审查注释、整理注释格式，或要求按照代码注释规范处理 Java 文件时，使用本技能。本技能用于统一生成和维护 Java 类注释模板、按 Git 对比 release 判断版本号、补充每行代码上方中文块注释、调整注释空行规则，并保持 Java 文件 UTF-8 无 BOM 编码。典型触发场景包括：补充类注释、更新 @version、检查 @author 来源、整理行尾注释、把注释放到代码上一行、检查注释是否符合规范、构建前检查 Java 注释风格。
-
OP_ACCEPT：接受新连接，拿到
SocketChannel，设为非阻塞，注册到同一 selector 关注OP_READ -
OP_READ：从 channel 读取数据到
ByteBuffer，注意检查read()返回值——0 表示暂时无数据（正常），-1 表示对端关闭连接，需取消 key 并关闭 channel - OP_WRITE：仅在写缓冲区满、写操作被挂起后才需显式注册；通常写完即清空 buffer，无需长期关注 OP_WRITE
- 每次处理完一个
SelectionKey，必须调用iterator.remove()，否则下次 select 仍会返回它，导致重复处理或CancelledKeyException
数据读写与粘包半包处理
NIO 不提供消息边界，TCP 是字节流协议，一次 read 可能只读到半个请求，也可能一次读到多个请求。不能依赖单次 read 完整读取一条业务消息。
立即学习“Java免费学习笔记（深入）”；
- 读取时用
ByteBuffer的flip()切换读模式，clear()或compact()重用 buffer；若数据未读完，保留剩余字节继续等待下一次就绪 - 推荐按协议头解析：比如固定长度头 + 变长体，或使用分隔符（如 \n）、长度前缀（4 字节 int 表示 body 长度）
- 避免把业务解码逻辑写进 selector 线程；可将完整消息封装成任务，提交给业务线程池异步处理，保持 IO 线程轻量
线程模型与扩展性控制
纯单线程 selector 模型适合 I/O 密集但计算轻量的场景（如转发、心跳检测）。一旦涉及复杂编解码、数据库访问或耗时逻辑，必须拆离。
- 常见做法是“1 个 accept 线程 + N 个 IO 线程 + M 个业务线程”：accept 线程只管新连接接入，IO 线程各自持有一个 selector 管理一批 channel，业务线程池专注处理消息
- 每个 IO 线程管理的 channel 数建议控制在 2000–5000，过多会导致单次 select 延迟升高；可通过连接数动态分配 channel 到不同 selector
- 务必捕获并记录
IOException和CancelledKeyException，特别是空轮询（Linux epoll bug）可能导致 CPU 100%，可用计数器+阈值触发 selector 重建缓解
