Java NIO聊天室服务端核心是事件驱动+非阻塞I/O，通过Selector单线程轮询多连接：1.初始化Selector和非阻塞ServerSocketChannel并注册OP_ACCEPT；2.循环select()处理OP_ACCEPT（接受并注册OP_READ）、OP_READ（读消息广播）；3.用线程安全集合管理Channel，校验有效性后广播；4.注意ByteBuffer重置、-1断连判断、异常时清理资源。
Java NIO 通过 Selector 实现聊天室服务端，核心在于用单线程轮询多个客户端连接，避免为每个连接创建线程，从而支撑高并发。关键不是“多线程”，而是“事件驱动 + 非阻塞 I/O”。下面分步骤说明实际怎么写。
1. 初始化 Selector 和 ServerSocketChannel
先打开 Selector，再创建非阻塞的 ServerSocketChannel，绑定端口，并注册 OP_ACCEPT 事件：
- 调用
ServerSocketChannel.open()获取通道 -
configureBlocking(false)设为非阻塞 -
bind(new InetSocketAddress(port))绑定地址 -
register(selector, SelectionKey.OP_ACCEPT)注册到 selector
2. 启动事件循环，处理不同就绪事件
用一个 while (true) 循环调用 selector.select() 阻塞等待就绪事件，然后遍历 selectedKeys() 处理：
- 如果是
OP_ACCEPT：接受新连接，将新SocketChannel设为非阻塞，注册OP_READ - 如果是
OP_READ：用ByteBuffer读取数据；注意检查read()返回值（-1 表示断开） - 如果是
OP_WRITE：通常用于写回响应，但聊天室中更常见的是“读到消息后立即广播”，所以一般不主动注册 OP_WRITE，而是读完后直接write()（需确保缓冲区有空间，否则可能只写部分）
3. 管理客户端连接和广播逻辑
不能依赖线程局部变量或全局静态集合随意操作 Channel，需安全维护连接列表：
JavaStoryDevelop
下载
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
立即学习“Java免费学习笔记（深入）”；
- 用
ConcurrentLinkedDeque或Collections.synchronizedSet(...)存储活跃的SocketChannel - 每次读到一条完整消息（比如按换行符或自定义协议拆包），遍历所有 channel 调用
write() - 写之前检查 channel 是否仍有效（
channel.isOpen() && channel.isConnected()），写失败时记得关闭并从集合中移除 - 建议封装一个简单的消息格式，如
"[user]: hello"，避免粘包——可用LineSeparator或固定长度头 + 内容方式
4. 注意细节：缓冲区、异常、半包与关闭
很多服务端跑着跑着就卡住或丢消息，问题常出在这些地方：
-
ByteBuffer每次读前要clear()（或flip()后compact()），否则位置错乱 - 读到 0 字节不表示断开，只是暂时无数据；读到 -1 才真断开，必须关闭 channel 并取消 key
- 广播时某个 client 写满 TCP 缓冲区会阻塞？不会，因为 channel 是非阻塞的，
write()返回实际写入字节数，小于 buffer 剩余容量时，可暂存未写完数据，下次OP_WRITE就绪再续写（但聊天室简单场景通常直接丢弃或限流） - 捕获
IOException后务必清理：取消 key、关闭 channel、从连接集合中移除
不复杂但容易忽略。真正上线还需加心跳、用户昵称管理、私聊标记、编码统一（如 UTF-8）、日志和限速，但基于 Selector 的主干逻辑就这四步。
