Java NIO不处理粘包和半包，需在应用层定义消息边界（定长、分隔符或长度前缀），并正确管理ByteBuffer的position/limit/capacity；Netty通过解码器简化该过程。
Java NIO 本身不处理粘包和半包，它只负责把 TCP 字节流读进 ByteBuffer。真正要解决分包与粘包，必须在应用层定义消息边界，并配合 ByteBuffer 的状态管理来正确提取完整业务消息。
核心问题：TCP 是流，不是消息
TCP 不保证“一次 write 对应一次 read”，也不保留业务逻辑中的消息边界。客户端发两次 write("LOGIN:A") 和 write("LOGOUT:B")，服务端一次 read() 可能拿到 "LOGIN:A LOGOUT:B"（粘包），也可能只拿到 "LOGIN:A L"（半包）。这不是 NIO 的 bug，而是 TCP 协议的天然特性。
三种主流边界定义方式
必须在协议设计阶段选一种，并在收发两端严格统一：
- 定长消息：每条消息固定长度（如 512 字节）。接收方每次尝试读满该长度；不足就缓存等待下次 read；超过则拆开处理。适合结构简单、长度可控的场景（如心跳、指令帧）。
-
分隔符标记：用特殊字节（如
\n、|或自定义字节序列）结尾。需扫描 ByteBuffer 查找分隔符位置，注意避免消息体中出现相同字节（可转义或选用不可见控制字符）。 -
长度前缀（推荐）：消息开头写入 2 或 4 字节表示后续内容长度（大端序）。例如：
[0x00, 0x0A] + "HELLO WORLD"表示后面有 10 字节数据。解析时先读头 → 判断长度是否合法 → 再读指定字节数。健壮、高效、无歧义，是工业级最常用方案。
ByteBuffer 状态管理是落地关键
光有协议不够，还得手动管好 position/limit/capacity：
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
立即学习“Java免费学习笔记（深入）”；
- 每次
channel.read(buffer)后，position移动到新数据末尾，但limit还是 capacity —— 必须调用flip()才能从头开始读数据。 - 如果一次读到多个完整包（如粘包），解析完第一个后，要用
compact()把剩余未读字节移到 buffer 开头，并重置 position/limit，为下一次 read 做准备。 - 如果读到半包（buffer 中数据不够一个完整消息），不能
clear()清空，必须保留已读内容，等下次 read 补齐。
用 Netty 可大幅简化
Netty 封装了完整的解码逻辑，开发者只需配置解码器：
-
LengthFieldBasedFrameDecoder(1024, 0, 2, 0, 2)：表示最大帧长 1024，长度字段偏移 0、占 2 字节，长度字段不包含自身，跳过前 2 字节再传给业务 handler。 - 自定义
MessageToMessageDecoder<ByteBuf>处理反序列化，此时入参已经是剥离粘包/半包后的干净消息对象。 - 避免在
channelRead()中直接操作原始 ByteBuf —— 解码器会确保传递的是完整、独立的业务消息。
不复杂但容易忽略
