Java NIO解决粘包问题的核心是在应用层添加协议头明确消息边界，推荐长度前缀法：消息头用2或4字节标明载荷长度，发送端先写长度再写内容，接收端需增量解析ByteBuffer，Netty可用LengthFieldBasedFrameDecoder简化处理。
Java NIO 中解决粘包问题，核心是在应用层加协议头明确消息边界——因为 TCP 本身是字节流，没有天然包概念，而 NIO 的 ByteBuffer 又是固定容量、需手动管理读写位置的，所以必须靠协议头让接收方知道“一条消息从哪开始、到哪结束”。
协议头推荐用长度前缀法
最常用也最稳妥的方式：在每条消息开头放 2 或 4 字节，表示后续有效载荷（payload）的长度（大端序）。例如：
- 前 4 字节是 0x00 00 00 14（十进制 20），后面紧跟 20 字节 JSON 数据；
- 发送时先写这 4 字节长度，再写实际内容，确保一次 write 完整发出；
- 接收方先尝试读够 4 字节 → 解出长度 → 再判断缓冲区是否已有足够字节数（4 + 长度）→ 满足就切出完整消息，剩余字节保留用于下次解析。
接收端必须增量解析缓冲区
NIO 不保证一次 read 就拿到整包，可能只读到半包，也可能一次读到多个包。所以不能每次 read 后就 clear 缓冲区：
- 维护一个可扩容的接收缓冲区（如 ByteBuffer.allocateDirect(4096)）；
- 每次 read() 后调用 flip() 切换读模式，检查当前数据量；
- 若已读 ≥ 头部长度（如 4 字节），就读出长度值；再看是否 ≥ 总长度（4 + payloadLen）；
- 满足则 slice() 出完整包，然后 compact() 缓冲区，把未读部分移到开头，position/limit 自动重置；
- 不满足就继续等待下一次 OP_READ，绝不能丢弃已读数据。
发送端要严格按头+体打包
不能直接 send 字符串或 byte[]，必须封装：
立即学习“Java免费学习笔记（深入）”；
- 计算 payload 的 UTF-8 字节数（str.getBytes(StandardCharsets.UTF_8).length）；
- 用 DataOutputStream 或 ByteBuffer.putInt() 先写入长度字段；
- 再写入 payload 字节数组；
- 确保整个头+体通过一次 channel.write() 发出（必要时用 write(ByteBuffer[]) 批量写）。
用 Netty 可跳过手动解析
如果项目允许引入 Netty，直接配解码器最省心：
- 加 LengthFieldBasedFrameDecoder(1024, 0, 4, 0, 4)：最大帧长 1024，长度字段从 offset 0 开始、占 4 字节，长度不包含自身，解码后跳过这 4 字节；
- 后续 ChannelInboundHandler.channelRead() 收到的就是剥离头部、无粘连、无截断的完整 ByteBuf；
- 业务逻辑不再碰原始缓冲区，避免 position/limit 管理出错。
