java nio selector 高效处理海量并发连接的核心在于委托操作系统监听事件，依赖非阻塞模式、精准注册事件类型、及时清理 selectedkeys 及资源复用。
Java NIO Selector 能处理大量并发连接，靠的不是“同时干活”，而是让操作系统代为监听——它把成千上万个 SocketChannel 的状态变化委托给底层 epoll（Linux）或 kqueue（macOS/BSD），自己只在有事件发生时才介入。关键不在“多”，而在“准”和“省”：不轮询、不空等、不浪费线程。
非阻塞是前提，一步错全盘崩
每个 Channel 必须在注册前调用 configureBlocking(false)。这是硬性要求，不是可选项。ServerSocketChannel 用于接收新连接，SocketChannel 用于收发数据，二者都必须是非阻塞模式。否则注册时直接抛 IllegalBlockingModeException，程序起不来。常见错误是只设了 ServerSocketChannel，忘了 accept 得到的 SocketChannel 也要设。
事件注册要分清角色，不能混搭
不同通道支持的事件类型不同，注册错了不仅无效，还会让 key 失效：
Java Maven Common
下载
Java Maven 项目审查工作流的通用输入处理。当 Java Maven 项目以 ZIP压缩包或 GitLab 仓库 URL 形式提供且需要...时使用。
- ServerSocketChannel 只能注册 OP_ACCEPT；注册 OP_READ 会静默失败，后续 select() 可能返回空就绪集
- SocketChannel 接收连接后，立即注册 OP_READ；需要回写时再临时追加 OP_WRITE，写完立刻取消——因为 TCP 缓冲区一有空间就触发 OP_WRITE，容易忙等
- 不要在一个 channel 上长期挂着 OP_WRITE，它不是“可以写”，而是“缓冲区腾出来了”，适合处理半包重试场景
select() 后必须手动清理 selectedKeys
每次 select() 返回后，遍历 selectedKeys() 集合处理事件，处理完必须用 Iterator.remove() 移除该 key。不能用集合自身的 remove()，也不能在迭代中直接调 key.cancel()，否则抛 ConcurrentModificationException。漏删会导致同个 key 下次又被返回，逻辑重复甚至崩溃。
内存和性能细节决定上限
撑住数万连接，光逻辑对还不够，还得控资源：
- ByteBuffer 别每个连接 new 一个——堆内 buffer 增加 GC 压力，堆外 buffer（DirectBuffer）不回收会耗尽 DirectMemory。建议用对象池（如 Netty 的 PooledByteBufAllocator）复用
- Selector.select() 默认阻塞，生产环境建议带超时参数（如 select(100)），避免因网络抖动或 bug 导致线程无限挂起
- 避免在 IO 线程里做耗时操作（如 JSON 解析、DB 查询），应交由业务线程池处理，防止阻塞整个 Selector 轮询
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
