java粘包拆包源于tcp无消息边界特性，解决关键是协议约定：①定长格式（如1024字节，不足补0）；②分隔符法（如 ，需转义避免冲突）；③头部长度字段（最通用，先读长度再读正文）；推荐用netty内置解码器简化处理。
Java 中的粘包和拆包问题，本质是 TCP 字节流特性导致的——它不维护消息边界，只管把数据当连续字节发出去。接收端一次 read 可能拿到多个消息，也可能只拿到半个消息。解决的关键不是“避免”，而是“约定协议”，让收发双方对消息怎么切分达成一致。
用定长消息格式最简单直接
所有消息统一长度，比如固定 1024 字节。不足补空字节（如 0x00），超长则截断或报错。接收方每次从输入流读满 1024 字节，再 trim 掉填充部分即可还原原始内容。
- 适合消息结构稳定、长度可预估的场景（如心跳包、状态上报）
- 编码时注意：发送前必须严格补足长度，否则后续所有包都会错位
- 解码时需判断是否读满，未满说明连接异常或数据中断，不能强行解析
用分隔符标记消息边界
在每条消息末尾加一个明确的分隔符，比如 或 |。接收端持续读取字节流，缓存未完整消息，直到遇到分隔符才切出一条完整消息。
- 实现轻量，适合文本协议（如自定义指令、日志推送）
- 分隔符必须确保不会出现在业务数据中，否则需转义（如将 替换为 \n）
- 缓冲区要设上限，防止恶意长消息耗尽内存
头部带长度字段最通用可靠
每个消息前加 2～4 字节的长度字段（如 int 类型占 4 字节），表示后续内容的真实字节数。接收端先读长度，再按该长度读取正文。
- 支持任意长度消息，无字符限制，是生产环境主流方案
- 读长度时必须保证字节数完整（如读 4 字节长度，不能只读到 3 字节就停）
- 建议配合 ByteBuffer 的 hasRemaining() 和 limit() 控制读取范围，避免越界
结合 Netty 等框架自动处理
手动处理粘包拆包容易出错，推荐使用 Netty 提供的内置解码器：
- FixedLengthFrameDecoder 对应定长方案
- LineBasedFrameDecoder 对应换行分隔符
- LengthFieldBasedFrameDecoder 对应头部长度字段（支持偏移、长度、调整值等灵活配置）
这些解码器已处理好缓冲、重试、粘包累积等细节，只需配置参数，业务逻辑专注消息内容本身。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
