Java NIO自定义协议编解码核心是解决粘包与半包，需严格按协议字段（魔数、版本、长度、指令、数据体）手动解析；推荐用Netty的ByteBuf实现，避免字节序错误、索引未重置、异常未捕获等陷阱。
Java NIO 实现自定义协议的编解码，核心在于将字节流按协议规则拆分成完整报文（解码），再将业务对象序列化为符合格式的字节流（编码）。关键不是用什么工具，而是控制 粘包 和 半包，并确保编解码逻辑与协议定义严格对齐。
协议设计是编解码的前提
没协议，就无从编解码。一个典型轻量自定义协议至少包含：
- 魔数（Magic Number）：固定 2~4 字节，用于快速识别合法报文（如 0xABCD）
- 版本号：方便后续协议升级兼容
- 报文长度（Length）：紧随魔数之后，标明整个报文体（不含头）的字节数，这是解决粘/半包的核心字段
- 指令类型（Command）：标识请求/响应、登录/心跳等语义
- 数据体（Body）：实际业务数据，可为 JSON、Protobuf、或自定义二进制结构
例如：4 字节魔数 + 1 字节版本 + 4 字节 length（int）+ 2 字节 command + N 字节 body。总长度 = 4+1+4+2+N。
使用 ByteBuf 手动编解码（Netty 风格）
Netty 的 ByteBuf 是最常用载体，它比原生 ByteBuffer 更易管理读写索引和自动扩容。解码需继承 ByteToMessageDecoder：
立即学习“Java免费学习笔记（深入）”；
deep-java-review
下载
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
- 重写
decode()方法，先检查是否至少有头部长度（如 11 字节）；不够则return等待更多数据 - 读取 length 字段，算出整包预期长度：
headerLen + length - 调用
in.readableBytes() >= expectedLen判断是否收到完整包；不够就 return，够了就切出子ByteBuf解析 - 解析时跳过魔数、版本、length、command，剩余部分交给业务反序列化器（如 FastJSON.parseObject(body, LoginReq.class)）
编码更简单：先写魔数、版本、command；再把 body 序列化为字节数组，写入并前置写入其长度；全程用 out.writeBytes(...) 即可。
避免常见陷阱
几个高频出错点必须注意：
-
长度字段未统一字节序：Java 默认大端（Network Byte Order），但若协议文档写“低字节在前”，就得用
writeIntLE()，否则服务端收不到正确长度 -
未重置读写索引：手动操作
ByteBuf后忘记readerIndex()或writerIndex()，导致下次读写出错 -
body 解析异常未捕获：比如 JSON 格式错误，应包装成
CorruptedFrameException抛出，让 Netty 断开连接，而不是静默吞掉或传脏数据 -
忽略缓冲区复用：在
encode()中不要 new 新ByteBuf，直接用out写入；解码中切出的子 buf 若不 retain，可能被池回收
不用 Netty？纯 NIO 也能做，但更琐碎
若坚持用原生 Selector + SocketChannel + ByteBuffer：
- 自己维护接收缓冲区（
ByteBuffer.allocateDirect(8192)），每次read()后检查是否读满；不满则 flip → decode → compact - decode 逻辑和 Netty 类似，但需手动管理 position/limit/capacity，容易越界或漏读
- 发送时同样要先序列化 body 得到 byte[]，再按协议拼接 header，最后分多次
write()直到全部发出（处理 write 返回值！）
不推荐纯 NIO 手写编解码——Netty 已把粘包、内存池、零拷贝、线程模型封装得足够健壮，自研反而增加维护成本和隐患。
