核心是正确识别消息边界，而非避免粘包半包；推荐长度前缀法——消息头4字节大端序存体长，接收端增量解析缓冲区，Netty用LengthFieldBasedFrameDecoder自动解码。
Java NIO 中解决 TCP 粘包和半包问题，核心不是“避免发生”，而是“正确识别消息边界”。因为 TCP 本身是字节流协议，没有天然的消息分界，而 NIO 的 ByteBuffer 又是固定容量、需手动管理读写位置的缓冲区，所以必须在应用层加一层结构，把连续字节流还原成一条条完整、独立的消息。
选一种可靠的消息边界方案
定长、分隔符、长度前缀这三种最常用，推荐长度前缀法：
- 定长消息：比如统一用 128 字节。接收方每次读满该长度再解析。适合心跳、状态上报等格式固定的场景；缺点是数据短时浪费带宽，数据超长则无法处理。
-
分隔符法：用
0x02等不可见字节作结尾。需确保真实业务数据中不出现该分隔符，否则要转义（如把\n）或改用更安全的控制字符。 -
长度前缀法（推荐）：消息开头放 2 或 4 字节（大端序），表示后续内容长度。例如前 4 字节是
0x00 00 00 1A（即 26），后面紧跟 26 字节有效载荷。容错性强、扩展性好，Netty 默认也采用它。
发送端要严格按协议打包
不能直接 channel.write() 原始字符串，得先封装头部再发：
- 计算 payload 字节数（如 JSON 字符串 UTF-8 编码后长度）
- 用
ByteBuffer或DataOutputStream先写入长度字段（如putInt(len)） - 再写入 payload 字节数组
- 确保一次
channel.write()发出完整头 + 体（避免因多次 write 导致头体分离）
接收端要增量解析缓冲区
NIO 场景下绝不能假设一次 read() 就拿到整包，必须维护一个可累积的接收缓冲区：
立即学习“Java免费学习笔记（深入）”；
- 每次从
SocketChannel读到数据就追加进缓冲区（如ByteBuffer动态扩容或用ArrayList<byte[]>拼接） - 循环检查：若已有数据 ≥ 头部长度（如 4 字节），就读出长度字段；再看总长度（头+体）是否 ≤ 当前缓冲区容量
- 满足条件就切出完整包，剩余字节用
compact()移至开头保留；不满足就继续等待下次 OP_READ - 切记：不能在未读完时调用
clear()，否则已读但未解析的数据会被丢弃
用 Netty 可大幅简化逻辑
手动管理缓冲区容易出错，Netty 提供了成熟解码器：
- 加
LengthFieldBasedFrameDecoder(1024, 0, 4, 0, 4)：最大帧长 1024，长度字段从偏移 0 开始占 4 字节，不包含自身，读完跳过 4 字节 - 后续
ChannelInboundHandler.channelRead()收到的就是剥离头部、无粘连、无截断的完整ByteBuf - 避免在业务 handler 中再操作原始 buffer——解码工作已由 pipeline 完成
