半包是TCP流式特性与ByteBuffer固定容量共同导致的必然现象，需通过缓存未读数据、compact()保留剩余内容、结合协议（定长/分隔符/长度前缀）识别包边界来处理，严禁new buffer、无条件clear或共用buffer。
Java NIO 非阻塞网络中，半包（读半包）是指一次 read() 调用只读到部分消息，不足以构成一个完整业务包。这不是通道或协议问题，而是 TCP 流式特性和 ByteBuffer 固定容量共同导致的必然现象。解决它的核心不是“避免”，而是“缓存 + 拆分 + 续读”——即把未解析完的数据暂存，等下次可读事件来临时拼接补全。
保持 ByteBuffer 可续读状态
每次 SocketChannel.read(buffer) 后，必须根据实际读取字节数判断是否已读满、是否够解析一条消息：
- 若返回值 > 0：说明有新数据，
buffer.position()已前移，但buffer.limit()仍为容量上限，需调用flip()切换至读模式（limit = position, position = 0）才能安全读取 - 若返回值 == 0：说明内核缓冲区暂无数据，不表示连接断开，直接跳过即可
- 若返回值 == -1：对端已关闭连接，应清理资源并取消注册
用 compact() 保留未读数据
当 flip() 后发现 buffer 中数据不足一个完整包（比如长度字段还没凑齐，或分隔符没出现），不能调用 clear()（会丢弃所有已读内容），而应调用 compact()：
-
compact()把未读部分（从position到limit）移到 buffer 开头，并设置position = remaining()、limit = capacity - 这样下一次
read()会从剩余空间继续追加，实现数据自然拼接 - 这是处理读半包最常用也最稳妥的缓冲策略
配合业务协议做边界识别
ByteBuffer 本身不理解业务语义，需结合协议规则判断“何时算读完一包”：
- 定长消息：检查
buffer.remaining()是否 ≥ 预期长度；不足则等待，足够则截取并position += length - 分隔符（如
\n）：在flip()后扫描buffer.array()或用get(i)查找，找到后提取[0, index+1)区间，再position = index + 1，最后compact() - 长度字段前缀（推荐）：先确保至少读到长度字段（如前 2 字节），用
getShort(0)解出 body 长度 L；若remaining() >= 2 + L，则提取完整包；否则继续等待
避免常见误操作
很多半包逻辑失效，其实源于对 ByteBuffer 状态管理不当：
- 每次 OP_READ 都 new 一个新 buffer —— 旧数据丢失，半包永远拼不起来
- read 后无条件 clear() —— 把刚读进来的字节全清掉，等于没读
- 只读一次就 reset/rewind 重试 —— 忽略了非阻塞下数据是分批到达的，必须循环或等待下次事件
- 多个 channel 共用同一个 buffer 实例 —— position 冲突，数据错位
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
