java nio处理半包问题的核心是可靠重组而非避免，需用可累积的bytebuffer配合flip/compact，并按长度域协议增量解析；推荐使用netty的lengthfieldbasedframedecoder自动处理，测试时须人为构造半包场景验证健壮性。
Java NIO 中处理半包问题，核心不是“避免发生”，而是“可靠重组”——因为 TCP 流式特性决定了半包必然存在，关键在于接收端如何从零散、不完整的字节流中识别并拼出完整消息。
必须维护一个可累积的接收缓冲区
不能每次 OP_READ 就新建 ByteBuffer 或调用 clear() 重置。真实场景中，一次 read() 可能只读到消息前半段，下一次才补上后半段。所以需长期持有缓冲区（如 ByteBuffer.allocateDirect(4096)），每次 read() 后用 buffer.put() 追加新数据，并通过 flip() 切换读模式；解析完部分数据后，用 compact() 把未读字节移到开头，保留 position 和 limit 状态供下次续读。
按协议头长度字段做增量解析
假设采用最常用的长度域前缀协议（如前 4 字节为大端 int 表示 body 长度）：
- 先检查 buffer 中是否有 ≥ 4 字节：没有 → 等待下次 read()
- 有，则 getInt(0) 读出 length 字段，校验是否合法（比如 ≤ 1MB、≥ 0）
- 再检查 buffer 总可用字节数是否 ≥ 4 + length：不足 → 继续等待；足够 → 调用 slice() 截取完整包（跳过头 4 字节），剩余字节 compact 后继续解析
别在业务逻辑里直接操作原始 buffer
手动管理 position/limit 容易出错，尤其多线程或高并发下。更稳妥的做法是接入 Netty，用 LengthFieldBasedFrameDecoder(8192, 0, 4, 0, 4) ——它自动完成上述所有步骤，后续 ChannelInboundHandler.channelRead() 收到的参数就是已剥离头部、无截断、无粘连的完整 ByteBuf，业务只需专注反序列化和处理。
测试时要主动触发半包场景
本地调试容易误判“一切正常”，因网络延迟低、数据小、一次读完。应人为构造半包验证逻辑是否健壮：
- 服务端 ByteBuffer 设为 128 字节，客户端发一条 300 字节消息
- 在 channel.read() 后插入 Thread.sleep(10)，模拟弱网延迟
- 连续快速发送多条小消息（如 3×50 字节），观察是否被合并成一整块再分拆
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
