消息原子分发与消息边界拆包必须解耦：前者保障单条消息对所有用户事务性送达，后者通过tlv协议+独立bytebuffer+compact缓存解决tcp粘包半包问题。
Java NIO 实现高性能聊天室时，“消息原子分发”和“消息边界拆包”是两个必须解耦、分别应对的核心问题：前者关乎逻辑一致性与可靠性，后者决定数据能否被正确识别和还原。混为一谈容易导致消息错乱、重复投递或内容截断——比如用户发一句“你好，今天开会吗？”，服务端却收到“你好，今”“天开会吗？”两段残缺文本，还可能把两条消息粘成“你好，今天开会吗？/hi，收到！”。下面从实操角度讲清怎么做。
消息边界处理：先确保“收得全、分得清”
NIO 的 ByteBuffer 是固定容量的字节容器，而网络传输天然存在 TCP 粘包与半包现象。不处理边界，就等于没真正读到完整消息。
- 拒绝“一次性分配大缓冲区”这种懒方案：比如直接 allocate(1024)，看似能装下多数消息，但遇到超长消息仍会截断；更严重的是，多个客户端消息可能挤进同一个 buffer，无法区分谁是谁。
- 推荐 TLV（Type-Length-Value）协议格式：在每条消息前加 4 字节 int 表示 body 长度（如 Java DataOutputStream.writeInt(len)）。服务端先读够 4 字节 → 解析出 length → 动态分配 capacity = length 的 buffer → 再读满该长度。这样既避免浪费，又精准界定消息范围。
-
每个 Channel 绑定独立 ByteBuffer（用 attachment）：不要多个 channel 共享一个 buffer。注册 clientChannel 时，通过
scKey.attach(ByteBuffer.allocate(128))把专属 buffer 挂载上去；后续 read 时从 key.attachment() 取，防止并发读写冲突。 -
半包场景要缓存未读完的数据：若当前 buffer 还差 3 字节才凑够 length，不能丢弃已有数据。调用
buffer.compact()把未读部分移到开头，下次 read 继续追加，直到凑齐整包。
原子分发：保证“一条消息，一次完整广播”
边界处理解决“收”，原子分发解决“发”。它不是指物理上同时推给所有人，而是确保单条消息对所有目标用户的送达过程具备事务性语义：要么全部成功，要么失败可追溯、可补偿。
-
禁止在循环中闭包捕获可变引用：像
for (session : sessions) { executor.submit(() -> send(msg, session)); }是危险的——循环变量 session 在多线程下会被覆盖，导致 A 用户收到 B 用户的消息。 -
任务对象必须固化上下文：构造 Runnable 或自定义 Task 类时，把 msg（建议 clone）、session（建议 copy）、msgId、timestamp 全部传入并设为 final。例如：
new DeliveryTask(msg.clone(), session.copy(), msgId)。 - 推送失败需有幂等回溯机制：为每条分发任务生成唯一 traceId，记录起始时间、目标 session 数、已成功数、失败 session 列表。若中途异常，可通过 traceId 查询状态，并对失败项重试（带最大重试次数+指数退避）。
- 区分推送阶段与业务阶段：鉴权、敏感词过滤、消息审计等应放在分发前完成；分发线程池只做序列化 + 网络 write。避免在 deliver() 中再查 DB 或调远程服务——那会拖慢整个队列。
线程协作模型：让边界处理与原子分发各司其职
两者不在同一层，也不该由同一个线程承担：
- IO 线程（Selector 所在线程）只负责：接收原始字节 → 按 TLV 拆出完整消息 → 封装成 Message 对象 → 提交到业务线程池。它必须轻量、非阻塞，绝不做任何耗时操作。
- 业务线程池（如 ThreadPoolExecutor）负责：解析消息类型 → 查目标会话列表 → 构建分发任务 → 提交到推送线程池。这里完成鉴权、路由、快照封装。
- 推送线程池（专用小队列）负责：执行 deliver() → write 到对应 SocketChannel → 记录 trace 日志。它与 IO 线程隔离，避免 write 阻塞 selector。
验证是否到位的三个信号
上线前用这三点快速自查：
- 发一条含中文、emoji、超长文本的消息（如 512 字符），服务端日志里是否只出现一行完整记录，而非多行碎片？
- 模拟 100 个用户同时发消息，检查是否有 session 收到不属于自己的 msgId，或某条消息在部分用户端缺失？
- 手动 kill 一个 client 连接瞬间，观察其他用户是否收到“xxx 下线”通知——这个事件必须和最后一条聊天消息严格有序，不能颠倒或丢失。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
