核心是用bytebuffer缓存字节流并自行解析消息边界：tcp无包概念，需按定长、分隔符或长度前缀（推荐）协议处理；bytebuffer需手动flip/compact管理状态；非阻塞写须检查返回值并暂存未写完buffer；netty的lengthfieldbasedframedecoder可自动解码完整消息。

核心在于用 ByteBuffer 缓存原始字节流，再在应用层按协议还原消息边界——TCP 本身不保证包边界，NIO 的 Channel 只负责搬运字节，真正识别“一条完整消息”必须靠你自己设计规则并精细操作 buffer。

选一种靠谱的消息边界协议

没有银弹，得根据业务选型：

• 定长消息：适合心跳、指令等结构固定场景。比如每条消息严格 32 字节，接收方每次尝试读满 32 字节；不够就等下次 read()，多了就 compact() 留下剩余字节。
• 分隔符法：用 或 0x00 等做结尾标记。注意真实数据里不能出现该符号——要么约定转义（如 写成 \n），要么选不可见控制字符（如 STX 0x02）。
• 长度前缀法（推荐）：消息开头放 2 或 4 字节表示后续内容长度（大端序）。例如前 2 字节是 0x001A（即 26），说明接下来 26 字节是一条完整消息。容错强、通用性好，Netty 默认也用这个。

ByteBuffer 必须手动管理 position 和 limit

NIO 不会自动切包，buffer 状态全靠你维护：

Java Development Manual

Java开发手册规约集合，基于阿里巴巴Java开发手册（嵩山版）。 涵盖7大维度：编程规约、异常日志、单元测试、安全规约、MySQL数据库、工程结构、设计规约。 当用户需要：(1) 编写或审查Java代码 (2) 检查命名/代码规范 (3) 处理异常和日志 (4) 编写单元测试 (5) 安全编码 (6) 数据库设...

下载

• 每次 channel.read(buffer) 后，position 移到新数据末尾，但 limit 还是 capacity —— 必须调用 flip() 才能进入读模式（limit = position，position = 0）。
• 如果一次读到多个完整包（比如 buffer 里有两条 32 字节消息），解析完第一条后，要调用 compact() —— 把未读部分移到开头，重置 position 和 limit，为下次 read() 做准备。
• 如果只收到半包（比如只读到长度字段或部分消息体），不能 clear()，必须保留已读数据，等下一次 read() 补齐后再继续解析。

非阻塞写也要防“写半包”

write() 返回值告诉你写了多少，不是“调了就完事”：

• 返回 0：内核缓冲区满，暂时写不了，需注册 OP_WRITE 等待就绪。
• 返回值大于 0 但小于 buffer.remaining()：只写了一部分，要把这个未写完的 buffer 存起来（比如挂到 SelectionKey 的 attachment 上）。
• OP_WRITE 触发时，从 attachment 取出 buffer 继续 write()；若仍没写完，保持 OP_WRITE 注册；若写完了，取消 OP_WRITE 并清理 attachment。
• 别在 write() 后无脑 clear()，也别每次 OP_WRITE 都 new 新 buffer——旧数据就丢了。

用 Netty 省力又可靠

手写解码容易出错，Netty 封装了成熟方案：

• 加一个 LengthFieldBasedFrameDecoder(1024, 0, 2, 0, 2)：最大帧长 1024，长度字段从偏移 0 开始占 2 字节，长度不包含自身，读完跳过这 2 字节。
• 后续 handler 的 channelRead() 收到的 msg，已经是剥离头、无粘连、无截断的完整对象（String 或 POJO），不用再碰原始 ByteBuf。

Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南