bytebuffer本身不解决粘包半包问题，关键在于用其配合协议设计与状态管理识别消息边界：需累积读取、按长度字段或分隔符解析、正确使用flip/compact/clear，避免固定大小buffer直接decode等陷阱。
ByteBuffer 本身不直接解决粘包和半包问题，它只是数据容器；真正起作用的是**如何使用 ByteBuffer 配合协议设计与状态管理来识别消息边界**。关键在于：不能依赖一次 read() 就得到一个完整业务消息，而要主动缓冲、累积、解析、截取。
用 ByteBuffer 手动维护接收缓冲区
服务端需持有一个可扩容的 ByteBuffer（如 HeapByteBuffer），每次 OP_READ 触发后，将新读到的数据 put 进去，再尝试从中按协议规则“切出”完整消息：
- 调用 flip() 切换为读模式，检查当前 buffer 中是否有足够字节构成一条合法消息
- 若不够（比如只读到一半长度字段或没遇到分隔符），就 compact() 保留未处理数据，等待下次 read 补充
- 若够了，就按协议提取完整消息（如先读 4 字节长度，再读对应字节数），然后 position += 消息总长度，继续处理剩余部分
- 处理完一批消息后，必要时 clear() 或重新分配更大 buffer 防止溢出
基于分隔符的拆包（适合文本协议）
若协议约定以 \n、<p>若协议约定以 <code>\n、\0 或自定义标记结尾，可用 ByteBuffer 扫描查找：
- 在 flip 后遍历 buffer 的 get(i)，寻找结束符位置
- 找到后，创建子 buffer（slice() + limit() 设置），解码为字符串
- 再调用 position(i + 1) 跳过分隔符，后续 compact 保留剩余内容
- 注意：避免每次从头扫描整个 buffer，应记录上次扫描起点（即“已确认无效前缀”位置）提升效率
基于长度字段的解包（推荐，更健壮）
主流做法是协议头部固定 2 或 4 字节表示 body 长度（如 intToBytes(len) + body）：
- 先确保 buffer 至少有 4 字节（头长度）——不够就 compact 等下次
- 用 getInt() 读出消息体长度
bodyLen - 再检查
buffer.remaining() >= bodyLen——不够也等下次 - 满足则 slice() 出 body 部分，position += 4 + bodyLen，完成一次完整消息提取
- 该方式无需搜索、无编码歧义、易于校验，Netty 的
LengthFieldBasedFrameDecoder底层逻辑即如此
避免常见陷阱
直接用固定大小 ByteBuffer（如 allocate(1024)）read 后就 decode，极易出错：
- buffer 太小 → 导致半包（只读到部分消息），但代码未判断 remaining 就强转字符串，丢数据或乱码
- buffer 太大且未控制读取量 → 一次 read 塞入多个消息 → 粘包，decode 出来是拼接串
- 忘记 flip/compact → position/limit 错乱，后续读写越界或跳过数据
- 重复使用同一 buffer 未重置 → 上次残留影响本次解析
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
