从“处理粘包”这个需求开写第一天实录。这其实是很多做网络编程的同学尤其是从业务转中间件、或者刚开始接触 Netty、自研 RPC 框架时第一个绕不过去的坎。网上讲 ByteBuffer 的文章不少但大多停留在“capacity 是啥、position 是啥”这种 API 层真正让人头疼的是为什么我用 ByteBuffer 读数据读着读着就乱了为什么我明明按顺序读数据还是对不上再一查啊还有粘包这种事。这篇文章不打算引用官方文档照本宣科就按我实际排查问题的顺序来聊。先把 ByteBuffer 的底层内存模型掰开揉碎再说它和 JVM 堆内存、堆外内存、甚至 Spark 这类计算框架里内存模型的关系最后落到一个能直接跑起来的粘包处理实战场景里。看完你应该能自己写一个简单的拆包工具也能大概理解 Netty 的 ByteToMessageDecoder 到底在帮你做什么。1. 为什么一上来要啃 ByteBuffer 内存模型很多人学网络编程上来先写 Socket套路是InputStream.read()配一个byte[]。这个写法你写点 Demo 没问题一旦进入高并发、长连接、数据量大的场景立刻露馅——GC 压力大、频繁拷贝、Byte 数组不好管理、读写状态全靠自己记。这时候你会接触到 ByteBuffer紧接着就发现这家伙比 byte[] 难用多了。难用不是它的错是因为你还不熟悉“状态索引 底层连续内存”这套设计哲学。ByteBuffer 本质上就是一块连续的内存区域加上几个游标cursor来标记当前读到哪、写到哪、能读多少。你把它想成一个带读写指针的字节数组就顺了。这里我想先说一个容易让人跑偏的点很多教程一上来就对比 HeapByteBuffer、DirectByteBuffer、MappedByteBuffer说堆内快还是堆外快。你如果刚开始学很容易被这些概念吓住。但实际上ByteBuffer 的核心难点不在“堆内还是堆外”而在于position、limit、capacity 三个游标在不同操作阶段如何变化。我把这个模型拆成一个更直白的方式capacity这块内存总共能装多少字节一旦分配基本不变。position当前读或写的游标位置就像你用手机看小说划到第几行。limit在写模式下它等于 capacity表示你最多能写到这在读模式下它等于上一次写结束时的 position表示有效数据到这里结束。这里面最大的坑是 flip。很多新手写完数据直接读发现读出来是空的或者读到一堆 0就是因为忘了调用 flipposition 还停在最后写入的位置limit 还是 capacity相当于你从这本书的第 500 页开始读而书总共 500 页你什么都读不到。我在实际教学和代码 review 时经常用一句话提醒flip 就是把“写模式”切换成“读模式”让 limit 记住你写了多少然后把 position 拨回 0。反过来读完数据想要继续写得调用 clear 或者 compact。clear 是把 position 拨回 0limit 拨回 capacity相当于整本书翻到开头之前的笔记不认了compact 则是把还没读完的数据往前挪让 position 指到未读数据的末尾相当于你翻到书签处继续从这往后写。这个内存模型如果用图形去画其实非常直观。但核心是要动手跑一遍不然你永远不会记住 flip 之后 position 和 limit 分别指向哪。2. 内存模型之间到底是什么关系标题里有“内存模型”很容易让人联想到 JVM 内存模型、Spark 内存模型搜索热词里也出现了 gcjava内存模型优化。这里我统一说说它们和 ByteBuffer 的距离理清这些概念你在选型和技术讨论时就不容易被绕晕了。JVM 内存模型讨论的是线程、主内存、工作内存之间的抽象关系和 JVM 运行时数据区堆、栈、元空间是两个维度的问题。ByteBuffer 更贴近运行时数据区的层面HeapByteBuffer 分配在堆内是一段 Java 管理的字节数组DirectByteBuffer 分配在堆外是 JNI 通过 Unsafe 分配的一块受 JVM 管理生命周期的原生内存。而 Spark 里讲的内存模型更多是对 JVM 堆内和堆外存储做的统一管理规划——它不是底层内存本身而是一种上层的内存调度策略。这么说吧ByteBuffer 是你搬砖时手里那块砖头JVM 内存模型是你工地的管理规范Spark 内存模型则是你老板对这一片工地的物料调度方案。三者的共同点是都得把有限的存储空间划分成可读写、有边界、有生命周期管理的区域。在实际网络编程中DirectByteBuffer 经常用来做 Socket I/O 的收发缓冲。原因是操作系统读取网络数据时如果数据在堆内JVM 得把这部分数据从堆内拷贝到一块堆外的中转区然后再交给系统调用如果用 DirectByteBuffer跳过堆内拷贝那一步省一次内存复制。但堆外内存不是免费的。它的分配和回收成本比堆内高很多而且不受 JVM GC 的常规管理是通过 Cleaner 机制或-XX:MaxDirectMemorySize来控制的。一旦你频繁创建 DirectByteBuffer 又忘记释放很容易把堆外内存打爆表现出来就是进程还在但内存看着像泄漏一样一直在涨GC 日志却干干净净。实战中最常见的一个优化场景是接收网络数据时用 DirectByteBuffer 接住操作系统缓冲区里的数据处理完后再转成堆内对象供业务使用。这里的核心逻辑不是“堆外一定快”而是“减少一次拷贝”。如果数据量小、频率低用堆内 ByteBuffer 反而更简单。所以建议你学的时候先掌握 HeapByteBuffer 的使用把 flip、compact、mark、reset 这些索引操作练熟再往 DirectByteBuffer 迁移最后再看 Netty 的 PooledByteBuf 是怎么办到内存池化的。层次感很重要一上来就追池化和零拷贝容易消化不良。3. 网络收包为什么会出现粘包和半包先跑题说一个场景某天你上线一个消息推送服务客户端发来 100 条数据服务端预估逻辑是每收一次消息就按一条完整数据处理。结果上线后日志里全是解析异常消息对不上号偶发数据串台。这种问题十有八九就是粘包和半包。粘包和半包产生的原因本质上是因为 TCP 是面向字节流的传输协议。它不像 UDP 那样有明确的消息边界你 send 两次操作系统可能会把两段数据合在一次 recv 里给你也可能你 send 一次数据量比较大对端分了好几次 recv 才收完。我拿水管来类比。你往水管里灌两颗完整的玻璃珠水流的视角里它们只是连续的一段水不会自动标记“这里是第一颗珠子结束这里是第二颗珠子开始”。接收端如果把水流分成一段段去切有可能把第一颗珠子的后半段和第二颗珠子的前半段切在一起。用专业点的术语说粘包连续发送多条消息接收端一次 read 拿到了多条消息的数据。半包一条消息的数据量过大或网络传输过程中被拆开接收端一次 read 拿到的只是消息的一部分。导致这两种情况的具体原因还挺多的。比如应用层写入频次高、数据量小TCP 的 Nagle 算法会尝试合并小报文再发送再比如接收端 Socket 缓冲区设置得不够大应用读取不及时数据在缓冲区里积压后一次性被读出来还有 MTU最大传输单元层面的拆分大包会被 IP 层拆成多个分片再传给对端。这时候你就明白了应用层必须自己约定协议定义消息边界。常见的解法有三种固定长度每条消息的字节数一样按长度切即可。简单但浪费带宽灵活性差。分隔符用特殊字符如\r\n或自定义分隔符标识一条消息结束。HTTP/1.x 早期的头部就类似这种思路。问题是内容里如果也出现分隔符你得处理转义。长度字段在消息头里用固定字节数表示消息体长度。像length payload这种格式应用最广HTTP/2、许多 RPC 框架比如 Dubbo都用类似方案。第三种方案是咱们这次实战要重点落地的。因为它在性能和通用性之间平衡得最好而且和 ByteBuffer 的配合也最自然。4. 用 ByteBuffer 实现一个可用的拆包解码器现在直接进入实战。咱们的需求是定义一个简单的二进制协议消息头固定 4 字节表示消息体长度后面跟消息体收到数据后能正确解析出每条完整消息并打印消息体内容。要求是一次 read 可能包含多条消息需要全部拆出来。一次 read 可能只收到半条消息需要暂存剩余字节等下次数据到达后继续拼装。不能因为临时缓冲区分配导致频繁 GC。我先把整体思路画出来这次不用图用步骤描述每次从 Socket 读数据到 ByteBuffer 后进入解码流程。解码流程先判断当前累积缓存中可读字节够不够 4 字节头部不够就等待下一次数据够就读取头部长度字段再判断总数据够不够一个完整包不够则等待够则按长度切出消息体交给业务处理剩余字节继续走解包流程。这里有个很核心的思路读到的数据先累积到一个待处理 ByteBuffer 中而不是直接消费。这个待处理 Buffer 就是解决半包的钥匙。给一个参考实现Java 语言public class LengthFieldBasedFrameDecoder { private ByteBuffer buffer; public LengthFieldBasedFrameDecoder(int capacity) { this.buffer ByteBuffer.allocate(capacity); } public void decode(ByteBuffer incoming) { // 将新读取的数据写入待处理 buffer append(incoming); // 循环解析直到不能再解出完整包 while (true) { // 切换到读模式此时的 position 是 0limit 是已写入字节数 buffer.flip(); // 如果剩余可读数据不足 4 字节说明连头部都没凑齐 if (buffer.remaining() Integer.BYTES) { // 保留未处理数据compact 会将未读数据移至开头 buffer.compact(); break; } // 读取头部长度 int length buffer.getInt(); // 合法性校验防止恶意超大长度 if (length 0 || length buffer.capacity() - Integer.BYTES) { throw new IllegalStateException(invalid length: length); } // 如果剩余数据不足一个完整消息体等待更多数据 if (buffer.remaining() length) { buffer.compact(); break; } // 截取出完整消息体 byte[] body new byte[length]; buffer.get(body); // 此时 position 已移动到本条消息末尾 // 处理业务逻辑比如打印 System.out.println(received msg: new String(body)); // 将剩余未读的数据 compact 到开头保持写模式 buffer.compact(); } } private void append(ByteBuffer incoming) { // incoming 当前处于读模式flip 后从 0 读到 limit incoming.flip(); // 把 incoming 中的数据写入 bufferbuffer 此时是写模式 while (incoming.hasRemaining()) { buffer.put(incoming.get()); } // 清空 incoming 引用方便下次复用 incoming.clear(); } }这段代码我有意写得偏教学一点方便你理解每一步在干什么。生产环境我不会这么写多半会直接切到 Netty 的ByteToMessageDecoder或者自研的时候把 buffer 改造成不用每次 flip compact 的环形结构。但思路是完全一致的。这里有两个细节你需要特别注意。第一append方法里我先把 incoming flip 成读模式再逐字节写入待处理 buffer。为什么不直接用incoming.get(byte[] dst)因为我不想让 incoming 内部索引状态变得太复杂逐字节虽然效率低一点但语义清晰。生产级代码我们一般会维护一个独立的读索引或者直接在 Netty 的ByteBuf层面操作因为它自带 readerIndex 和 writerIndex天然就是读写分离的。第二compact()被我用在好多地方。它和clear()的区别特别重要clear()是把 position 归零、limit 归 capacity不管里面还有没有未读数据compact()则是“保留未读数据把 position 挪到未读数据末尾”。我们的场景里解包解到一半剩余数据可能是半包的一部分绝对不能 clear 掉否则数据就丢了。这是我见过最多人踩的坑。5. decode 流程中的索引状态演变我相信只看上面那段代码还是有不少队友会卡在“为什么 while 循环里要反复 flip 和 compact”。我拿一个具体例子把每一步的 position、limit 变化铺开讲。假设缓冲区 capacity 是 32 字节。第一次从 Socket 读入了 10 个字节这 10 个字节包含了一条完整消息前 4 字节长度值为 6后面正好 6 字节消息体。append 之后buffer 的写入指针 position 停在 10limit 为 32capacity 为 32。进入 while 循环的第一步buffer.flip()。翻转为读模式position 变为 0limit 变为 10。这一步的语义是现在开始读读到 10 为止10 之后都是无效区。接着buffer.remaining()是 10大于 4 字节所以可以读头部。buffer.getInt()读走 4 个字节position 变成 4。此时我们一个 int 拿到了 length 6。校验 length 没问题后继续看buffer.remaining()这时是 6正好等于 length说明一个完整的消息体就在缓冲区里。接着byte[] body new byte[6]; buffer.get(body)position 变为 10。这时循环继续再次 buffer.flip()不对这个时候 buffer 已经处于读模式position 在 10limit 还是 10remaining 0按代码逻辑开头判断buffer.remaining() Integer.BYTES条件成立然后 buffer.compact()。compact() 在 buffer 的 position10、limit10 的情况下语义是把 position 到 limit 之间的未读数据0 字节移到开头然后把 position 设置为 0limit 设置为 capacity 32。所以 compact 之后buffer 又回到了写模式position0limit32。循环 break等待下一次网络数据。这个例子是比较完美的“一条完整消息刚好一次到达”。再来看半包的情况。假设第一次只收到 2 个字节这 2 个字节是消息头的前半部分。append 后 position2flip 后 limit2remaining2小于 4没法读 int于是 compact。compact 时未读数据就是那 2 个字节它会被挪到 buffer 的 0 和 1 位置position 置为 2limit 回到 32。下一次 append 时新的数据从 position2 接着写这样那 2 个旧的字节和新的数据拼接在一起慢慢凑齐头部和消息体。这个过程循环往复直到某一次循环里连续解析出多条完整消息。比如缓冲区累积了 40 字节而每条消息只有 10 字节while 循环就会连续解析 4 次每次解析完 compact直到 remaining 不足以构成一个完整包头才停。理解了索引变化你回头再看flip和compact这对操作就不会觉得它们是玄学了。它们本质上就是在“读模式”和“写模式”之间来回切换并保证未消费的数据不丢失。嗯可以这么记flip 是准备读compact 是准备写且保留未读数据。就像你泡茶flip 是把杯口朝上准备喝compact 是喝完把茶叶渣拨到一边给新茶叶腾地方。6. 生产实践中的细节调优与资源控制上面的代码展示了核心逻辑但真要放到生产环境还有几个地方我必须强调因为我都踩过。第一ByteBuffer 容量设置。如果你的协议单条消息最大是 1MB那 buffer.capacity 至少得能容纳 1MB 加头部。但这还不是全部考虑极端情况TCP 缓冲区里积压了大量数据一次性 read 回来的数据可能远大于单条消息。此时如果 buffer 容量设置过小append 就会抛BufferOverflowException。所以要么把 buffer 容量设置为“单条最大消息 一个合理的余量”要么在 append 时检测剩余空间不够了就扩容。Netty 的 ByteBuf 是支持动态扩容的原生 ByteBuffer 你需要自己做扩容分配一个更大的新 buffer把旧数据拷过去。第二length 字段的合法性问题。这是个很现实的安全隐患。如果一个恶意客户端构造一个 length 0x7FFFFFFF 的包头你的程序就会开始等待一个根本不可能到达的超大消息导致连接一直占着缓冲区和线程资源。所以每次 readInt 之后必须做合法性校验。生产上一般还会约定一个最大长度上限超过直接抛异常断连。第三ByteBuffer 的初始分配位置。如果是堆内缓冲区分配高频时也会产生 GC 压力。Netty 给出了一套比较好的解法内存池 线程局部缓存。我们自研框架时如果不想搞那么重也可以用 ThreadLocal 存放 ByteBuffer避免每个连接创建新 buffer。第四别忘了粘包里可能混合了多种协议。我做过的某个老系统有个连接既跑心跳又跑业务消息消息头里除了长度还有类型字段。这种场景下你 decode 出来的不只是“一条消息”还可能是“一条消息 一条特殊控制帧”。所以 decode 完消息体后最好根据消息头里的 type 字段分发给不同处理器不要把协议解析和业务逻辑耦合在一起。在这之外还有一个经常被忽略的点ByteBuffer 的字节序。ByteBuffer buffer ByteBuffer.allocate(8); buffer.order(ByteOrder.LITTLE_ENDIAN);如果你收到的 length 字段是用小端序表示的而你的代码默认按大端序 readInt那么同一个数值读出来会完全不一样。比如 4 字节01 00 00 00大端读出来是 16777216小端读出来才是 1。这个错很隐蔽因为包头还是能解析出来但长度值巨大或为 0看起来就像数据被截断了。协议规范里一般会明确写清楚字节序。比如大多数网络协议默认大端序但有些私有协议为了性能或习惯会用小端。实战中遇到“数据格式看起来都对就是解析不出来”的情况第一件事去查协议定义端的字节序。另外还有字符串编码的问题。二进制协议里字符串考究点的会带上字符集编码标记省事的直接在协议文档里写死 UTF-8。调用new String(body)不传 charset 的写法在本地测试没问题一上线在默认编码不是 UTF-8 的机器上就会乱码。所以建议养成写StandardCharsets.UTF_8的习惯。7. 常见问题排查速查表我在培训新人时整理过一份网络收包解析常见问题的速查表这里直接分享出来你可以对照排查现象可能原因排查方向读到的数据开头几字节不对字节序不一致检查 ByteOrder 设置消息总是被截断成两段buffer 容量不足或接收端读取不及时调大容量调整读取频率解析出超大长度值长度字段被读错小端/大端不匹配数据损坏校验字节序增加长度合法范围判断消息整体错位一条但无正则规律粘包处理逻辑存在漏读或多读在拆包时打印 position 和 limit偶发 NullPointer 或数组越界get(byte[])校验长度前未判断 remaining先判断 remaining 再读数据堆外内存持续增长DirectByteBuffer 未释放或分配过多用-XX:MaxDirectMemorySize限制检查释放逻辑GC 频繁吞吐下降HeapByteBuffer 高频分配改用内存池或线程局部 ByteBuffer你能看到大部分问题并不是 ByteBuffer 本身的 bug而是我们使用索引时状态混乱导致的。真正动手调这个问题的最好手段就是加日志把每次 flip、compact、getInt 之后的 position 和 limit 打出来。等你能像我一样在脑子里模拟这些索引的移动绝大部分收发数据的疑难杂症都能轻松定位。最后分享一个小技巧。调试 ByteBuffer 相关代码时我习惯在 decode 的核心入口临时用buffer.duplicate()拿到一个共享内容的副本再在副本上做 peek 操作比如提前看看 length 字段是多少但不动主 buffer 的 position 和 limit。这个技巧在排查“少读了 4 字节”或者“多读了 2 字节”这种问题时异常好用。8. 扩展一步从 ByteBuffer 到 Netty ByteBuf搞定原生 ByteBuffer 之后我强烈建议你去用一下 Netty 的 ByteBuf。倒不是说 ByteBuf 比 ByteBuffer 高级多少而是你会发现它针对我们前面遇到的痛点做了不少改进。比如 ByteBuf 拆分了 readerIndex 和 writerIndex你不再需要手动 flip 和 compact。它天然知道哪些数据是可读的哪些位置可以继续写。每当你读完一部分数据只需要discardReadBytes()把已读区域释放出来或者干脆不释放等写入指针到头了再统一处理。更关键的是ByteBuf 支持readSlice、retainedSlice这种零拷贝视图操作。拆包时你可以直接readerIndex(4).readSlice(length)把消息体作为一个独立的 ByteBuf 切片交给业务层不需要像原生 ByteBuffer 一样必须byte[] body new byte[length]再 get 一次。Netty 的LengthFieldBasedFrameDecoder也是个现成的拆包器配置几个参数就能用maxFrameLength单条消息最大长度。lengthFieldOffset长度字段偏移量。lengthFieldLength长度字段字节数。lengthAdjustment长度字段的值加上这个调整值等于实际消息体长度。initialBytesToStrip解析后跳过的字节数。我印象很深的是有一次处理一个老系统的协议消息头里有 2 字节的版本号然后才是 4 字节长度长度值包含头部自身而不包含版本号。直接用LengthFieldBasedFrameDecoder(1024, 2, 4, 0, 2)就把问题解决了免去了自己写状态机的麻烦。但这里得提醒一句框架能帮你解决 90% 的常规场景剩下 10% 的私有协议、特殊标志位、压缩消息头、多级嵌套长度字段你还是得回到原始 ByteBuffer 自己动手。这也是为什么我在标题里强调“从 ByteBuffer 内存模型出发”的原因——地基不打好上层框架用起来总归有点心虚。我个人在实际操作中的体会是ByteBuffer 这关早晚要过。你可以在 Netty 的封装下开心写业务代码很多年但只要遇到一次跨语言对接、一次私有协议解析、一次堆外内存排查你就会发现之前偷的懒都得加倍还回来。反而是一开始就把 position、limit、flip、compact 吃透的人后面会顺很多。别急拿个小例子反复跑把每一行索引变化都打印出来你也能在一天之内把它彻底拿下。 ByteBuffer内存模型与粘包拆包实战详解
从“处理粘包”这个需求开写第一天实录。这其实是很多做网络编程的同学尤其是从业务转中间件、或者刚开始接触 Netty、自研 RPC 框架时第一个绕不过去的坎。网上讲 ByteBuffer 的文章不少但大多停留在“capacity 是啥、position 是啥”这种 API 层真正让人头疼的是为什么我用 ByteBuffer 读数据读着读着就乱了为什么我明明按顺序读数据还是对不上再一查啊还有粘包这种事。这篇文章不打算引用官方文档照本宣科就按我实际排查问题的顺序来聊。先把 ByteBuffer 的底层内存模型掰开揉碎再说它和 JVM 堆内存、堆外内存、甚至 Spark 这类计算框架里内存模型的关系最后落到一个能直接跑起来的粘包处理实战场景里。看完你应该能自己写一个简单的拆包工具也能大概理解 Netty 的 ByteToMessageDecoder 到底在帮你做什么。1. 为什么一上来要啃 ByteBuffer 内存模型很多人学网络编程上来先写 Socket套路是InputStream.read()配一个byte[]。这个写法你写点 Demo 没问题一旦进入高并发、长连接、数据量大的场景立刻露馅——GC 压力大、频繁拷贝、Byte 数组不好管理、读写状态全靠自己记。这时候你会接触到 ByteBuffer紧接着就发现这家伙比 byte[] 难用多了。难用不是它的错是因为你还不熟悉“状态索引 底层连续内存”这套设计哲学。ByteBuffer 本质上就是一块连续的内存区域加上几个游标cursor来标记当前读到哪、写到哪、能读多少。你把它想成一个带读写指针的字节数组就顺了。这里我想先说一个容易让人跑偏的点很多教程一上来就对比 HeapByteBuffer、DirectByteBuffer、MappedByteBuffer说堆内快还是堆外快。你如果刚开始学很容易被这些概念吓住。但实际上ByteBuffer 的核心难点不在“堆内还是堆外”而在于position、limit、capacity 三个游标在不同操作阶段如何变化。我把这个模型拆成一个更直白的方式capacity这块内存总共能装多少字节一旦分配基本不变。position当前读或写的游标位置就像你用手机看小说划到第几行。limit在写模式下它等于 capacity表示你最多能写到这在读模式下它等于上一次写结束时的 position表示有效数据到这里结束。这里面最大的坑是 flip。很多新手写完数据直接读发现读出来是空的或者读到一堆 0就是因为忘了调用 flipposition 还停在最后写入的位置limit 还是 capacity相当于你从这本书的第 500 页开始读而书总共 500 页你什么都读不到。我在实际教学和代码 review 时经常用一句话提醒flip 就是把“写模式”切换成“读模式”让 limit 记住你写了多少然后把 position 拨回 0。反过来读完数据想要继续写得调用 clear 或者 compact。clear 是把 position 拨回 0limit 拨回 capacity相当于整本书翻到开头之前的笔记不认了compact 则是把还没读完的数据往前挪让 position 指到未读数据的末尾相当于你翻到书签处继续从这往后写。这个内存模型如果用图形去画其实非常直观。但核心是要动手跑一遍不然你永远不会记住 flip 之后 position 和 limit 分别指向哪。2. 内存模型之间到底是什么关系标题里有“内存模型”很容易让人联想到 JVM 内存模型、Spark 内存模型搜索热词里也出现了 gcjava内存模型优化。这里我统一说说它们和 ByteBuffer 的距离理清这些概念你在选型和技术讨论时就不容易被绕晕了。JVM 内存模型讨论的是线程、主内存、工作内存之间的抽象关系和 JVM 运行时数据区堆、栈、元空间是两个维度的问题。ByteBuffer 更贴近运行时数据区的层面HeapByteBuffer 分配在堆内是一段 Java 管理的字节数组DirectByteBuffer 分配在堆外是 JNI 通过 Unsafe 分配的一块受 JVM 管理生命周期的原生内存。而 Spark 里讲的内存模型更多是对 JVM 堆内和堆外存储做的统一管理规划——它不是底层内存本身而是一种上层的内存调度策略。这么说吧ByteBuffer 是你搬砖时手里那块砖头JVM 内存模型是你工地的管理规范Spark 内存模型则是你老板对这一片工地的物料调度方案。三者的共同点是都得把有限的存储空间划分成可读写、有边界、有生命周期管理的区域。在实际网络编程中DirectByteBuffer 经常用来做 Socket I/O 的收发缓冲。原因是操作系统读取网络数据时如果数据在堆内JVM 得把这部分数据从堆内拷贝到一块堆外的中转区然后再交给系统调用如果用 DirectByteBuffer跳过堆内拷贝那一步省一次内存复制。但堆外内存不是免费的。它的分配和回收成本比堆内高很多而且不受 JVM GC 的常规管理是通过 Cleaner 机制或-XX:MaxDirectMemorySize来控制的。一旦你频繁创建 DirectByteBuffer 又忘记释放很容易把堆外内存打爆表现出来就是进程还在但内存看着像泄漏一样一直在涨GC 日志却干干净净。实战中最常见的一个优化场景是接收网络数据时用 DirectByteBuffer 接住操作系统缓冲区里的数据处理完后再转成堆内对象供业务使用。这里的核心逻辑不是“堆外一定快”而是“减少一次拷贝”。如果数据量小、频率低用堆内 ByteBuffer 反而更简单。所以建议你学的时候先掌握 HeapByteBuffer 的使用把 flip、compact、mark、reset 这些索引操作练熟再往 DirectByteBuffer 迁移最后再看 Netty 的 PooledByteBuf 是怎么办到内存池化的。层次感很重要一上来就追池化和零拷贝容易消化不良。3. 网络收包为什么会出现粘包和半包先跑题说一个场景某天你上线一个消息推送服务客户端发来 100 条数据服务端预估逻辑是每收一次消息就按一条完整数据处理。结果上线后日志里全是解析异常消息对不上号偶发数据串台。这种问题十有八九就是粘包和半包。粘包和半包产生的原因本质上是因为 TCP 是面向字节流的传输协议。它不像 UDP 那样有明确的消息边界你 send 两次操作系统可能会把两段数据合在一次 recv 里给你也可能你 send 一次数据量比较大对端分了好几次 recv 才收完。我拿水管来类比。你往水管里灌两颗完整的玻璃珠水流的视角里它们只是连续的一段水不会自动标记“这里是第一颗珠子结束这里是第二颗珠子开始”。接收端如果把水流分成一段段去切有可能把第一颗珠子的后半段和第二颗珠子的前半段切在一起。用专业点的术语说粘包连续发送多条消息接收端一次 read 拿到了多条消息的数据。半包一条消息的数据量过大或网络传输过程中被拆开接收端一次 read 拿到的只是消息的一部分。导致这两种情况的具体原因还挺多的。比如应用层写入频次高、数据量小TCP 的 Nagle 算法会尝试合并小报文再发送再比如接收端 Socket 缓冲区设置得不够大应用读取不及时数据在缓冲区里积压后一次性被读出来还有 MTU最大传输单元层面的拆分大包会被 IP 层拆成多个分片再传给对端。这时候你就明白了应用层必须自己约定协议定义消息边界。常见的解法有三种固定长度每条消息的字节数一样按长度切即可。简单但浪费带宽灵活性差。分隔符用特殊字符如\r\n或自定义分隔符标识一条消息结束。HTTP/1.x 早期的头部就类似这种思路。问题是内容里如果也出现分隔符你得处理转义。长度字段在消息头里用固定字节数表示消息体长度。像length payload这种格式应用最广HTTP/2、许多 RPC 框架比如 Dubbo都用类似方案。第三种方案是咱们这次实战要重点落地的。因为它在性能和通用性之间平衡得最好而且和 ByteBuffer 的配合也最自然。4. 用 ByteBuffer 实现一个可用的拆包解码器现在直接进入实战。咱们的需求是定义一个简单的二进制协议消息头固定 4 字节表示消息体长度后面跟消息体收到数据后能正确解析出每条完整消息并打印消息体内容。要求是一次 read 可能包含多条消息需要全部拆出来。一次 read 可能只收到半条消息需要暂存剩余字节等下次数据到达后继续拼装。不能因为临时缓冲区分配导致频繁 GC。我先把整体思路画出来这次不用图用步骤描述每次从 Socket 读数据到 ByteBuffer 后进入解码流程。解码流程先判断当前累积缓存中可读字节够不够 4 字节头部不够就等待下一次数据够就读取头部长度字段再判断总数据够不够一个完整包不够则等待够则按长度切出消息体交给业务处理剩余字节继续走解包流程。这里有个很核心的思路读到的数据先累积到一个待处理 ByteBuffer 中而不是直接消费。这个待处理 Buffer 就是解决半包的钥匙。给一个参考实现Java 语言public class LengthFieldBasedFrameDecoder { private ByteBuffer buffer; public LengthFieldBasedFrameDecoder(int capacity) { this.buffer ByteBuffer.allocate(capacity); } public void decode(ByteBuffer incoming) { // 将新读取的数据写入待处理 buffer append(incoming); // 循环解析直到不能再解出完整包 while (true) { // 切换到读模式此时的 position 是 0limit 是已写入字节数 buffer.flip(); // 如果剩余可读数据不足 4 字节说明连头部都没凑齐 if (buffer.remaining() Integer.BYTES) { // 保留未处理数据compact 会将未读数据移至开头 buffer.compact(); break; } // 读取头部长度 int length buffer.getInt(); // 合法性校验防止恶意超大长度 if (length 0 || length buffer.capacity() - Integer.BYTES) { throw new IllegalStateException(invalid length: length); } // 如果剩余数据不足一个完整消息体等待更多数据 if (buffer.remaining() length) { buffer.compact(); break; } // 截取出完整消息体 byte[] body new byte[length]; buffer.get(body); // 此时 position 已移动到本条消息末尾 // 处理业务逻辑比如打印 System.out.println(received msg: new String(body)); // 将剩余未读的数据 compact 到开头保持写模式 buffer.compact(); } } private void append(ByteBuffer incoming) { // incoming 当前处于读模式flip 后从 0 读到 limit incoming.flip(); // 把 incoming 中的数据写入 bufferbuffer 此时是写模式 while (incoming.hasRemaining()) { buffer.put(incoming.get()); } // 清空 incoming 引用方便下次复用 incoming.clear(); } }这段代码我有意写得偏教学一点方便你理解每一步在干什么。生产环境我不会这么写多半会直接切到 Netty 的ByteToMessageDecoder或者自研的时候把 buffer 改造成不用每次 flip compact 的环形结构。但思路是完全一致的。这里有两个细节你需要特别注意。第一append方法里我先把 incoming flip 成读模式再逐字节写入待处理 buffer。为什么不直接用incoming.get(byte[] dst)因为我不想让 incoming 内部索引状态变得太复杂逐字节虽然效率低一点但语义清晰。生产级代码我们一般会维护一个独立的读索引或者直接在 Netty 的ByteBuf层面操作因为它自带 readerIndex 和 writerIndex天然就是读写分离的。第二compact()被我用在好多地方。它和clear()的区别特别重要clear()是把 position 归零、limit 归 capacity不管里面还有没有未读数据compact()则是“保留未读数据把 position 挪到未读数据末尾”。我们的场景里解包解到一半剩余数据可能是半包的一部分绝对不能 clear 掉否则数据就丢了。这是我见过最多人踩的坑。5. decode 流程中的索引状态演变我相信只看上面那段代码还是有不少队友会卡在“为什么 while 循环里要反复 flip 和 compact”。我拿一个具体例子把每一步的 position、limit 变化铺开讲。假设缓冲区 capacity 是 32 字节。第一次从 Socket 读入了 10 个字节这 10 个字节包含了一条完整消息前 4 字节长度值为 6后面正好 6 字节消息体。append 之后buffer 的写入指针 position 停在 10limit 为 32capacity 为 32。进入 while 循环的第一步buffer.flip()。翻转为读模式position 变为 0limit 变为 10。这一步的语义是现在开始读读到 10 为止10 之后都是无效区。接着buffer.remaining()是 10大于 4 字节所以可以读头部。buffer.getInt()读走 4 个字节position 变成 4。此时我们一个 int 拿到了 length 6。校验 length 没问题后继续看buffer.remaining()这时是 6正好等于 length说明一个完整的消息体就在缓冲区里。接着byte[] body new byte[6]; buffer.get(body)position 变为 10。这时循环继续再次 buffer.flip()不对这个时候 buffer 已经处于读模式position 在 10limit 还是 10remaining 0按代码逻辑开头判断buffer.remaining() Integer.BYTES条件成立然后 buffer.compact()。compact() 在 buffer 的 position10、limit10 的情况下语义是把 position 到 limit 之间的未读数据0 字节移到开头然后把 position 设置为 0limit 设置为 capacity 32。所以 compact 之后buffer 又回到了写模式position0limit32。循环 break等待下一次网络数据。这个例子是比较完美的“一条完整消息刚好一次到达”。再来看半包的情况。假设第一次只收到 2 个字节这 2 个字节是消息头的前半部分。append 后 position2flip 后 limit2remaining2小于 4没法读 int于是 compact。compact 时未读数据就是那 2 个字节它会被挪到 buffer 的 0 和 1 位置position 置为 2limit 回到 32。下一次 append 时新的数据从 position2 接着写这样那 2 个旧的字节和新的数据拼接在一起慢慢凑齐头部和消息体。这个过程循环往复直到某一次循环里连续解析出多条完整消息。比如缓冲区累积了 40 字节而每条消息只有 10 字节while 循环就会连续解析 4 次每次解析完 compact直到 remaining 不足以构成一个完整包头才停。理解了索引变化你回头再看flip和compact这对操作就不会觉得它们是玄学了。它们本质上就是在“读模式”和“写模式”之间来回切换并保证未消费的数据不丢失。嗯可以这么记flip 是准备读compact 是准备写且保留未读数据。就像你泡茶flip 是把杯口朝上准备喝compact 是喝完把茶叶渣拨到一边给新茶叶腾地方。6. 生产实践中的细节调优与资源控制上面的代码展示了核心逻辑但真要放到生产环境还有几个地方我必须强调因为我都踩过。第一ByteBuffer 容量设置。如果你的协议单条消息最大是 1MB那 buffer.capacity 至少得能容纳 1MB 加头部。但这还不是全部考虑极端情况TCP 缓冲区里积压了大量数据一次性 read 回来的数据可能远大于单条消息。此时如果 buffer 容量设置过小append 就会抛BufferOverflowException。所以要么把 buffer 容量设置为“单条最大消息 一个合理的余量”要么在 append 时检测剩余空间不够了就扩容。Netty 的 ByteBuf 是支持动态扩容的原生 ByteBuffer 你需要自己做扩容分配一个更大的新 buffer把旧数据拷过去。第二length 字段的合法性问题。这是个很现实的安全隐患。如果一个恶意客户端构造一个 length 0x7FFFFFFF 的包头你的程序就会开始等待一个根本不可能到达的超大消息导致连接一直占着缓冲区和线程资源。所以每次 readInt 之后必须做合法性校验。生产上一般还会约定一个最大长度上限超过直接抛异常断连。第三ByteBuffer 的初始分配位置。如果是堆内缓冲区分配高频时也会产生 GC 压力。Netty 给出了一套比较好的解法内存池 线程局部缓存。我们自研框架时如果不想搞那么重也可以用 ThreadLocal 存放 ByteBuffer避免每个连接创建新 buffer。第四别忘了粘包里可能混合了多种协议。我做过的某个老系统有个连接既跑心跳又跑业务消息消息头里除了长度还有类型字段。这种场景下你 decode 出来的不只是“一条消息”还可能是“一条消息 一条特殊控制帧”。所以 decode 完消息体后最好根据消息头里的 type 字段分发给不同处理器不要把协议解析和业务逻辑耦合在一起。在这之外还有一个经常被忽略的点ByteBuffer 的字节序。ByteBuffer buffer ByteBuffer.allocate(8); buffer.order(ByteOrder.LITTLE_ENDIAN);如果你收到的 length 字段是用小端序表示的而你的代码默认按大端序 readInt那么同一个数值读出来会完全不一样。比如 4 字节01 00 00 00大端读出来是 16777216小端读出来才是 1。这个错很隐蔽因为包头还是能解析出来但长度值巨大或为 0看起来就像数据被截断了。协议规范里一般会明确写清楚字节序。比如大多数网络协议默认大端序但有些私有协议为了性能或习惯会用小端。实战中遇到“数据格式看起来都对就是解析不出来”的情况第一件事去查协议定义端的字节序。另外还有字符串编码的问题。二进制协议里字符串考究点的会带上字符集编码标记省事的直接在协议文档里写死 UTF-8。调用new String(body)不传 charset 的写法在本地测试没问题一上线在默认编码不是 UTF-8 的机器上就会乱码。所以建议养成写StandardCharsets.UTF_8的习惯。7. 常见问题排查速查表我在培训新人时整理过一份网络收包解析常见问题的速查表这里直接分享出来你可以对照排查现象可能原因排查方向读到的数据开头几字节不对字节序不一致检查 ByteOrder 设置消息总是被截断成两段buffer 容量不足或接收端读取不及时调大容量调整读取频率解析出超大长度值长度字段被读错小端/大端不匹配数据损坏校验字节序增加长度合法范围判断消息整体错位一条但无正则规律粘包处理逻辑存在漏读或多读在拆包时打印 position 和 limit偶发 NullPointer 或数组越界get(byte[])校验长度前未判断 remaining先判断 remaining 再读数据堆外内存持续增长DirectByteBuffer 未释放或分配过多用-XX:MaxDirectMemorySize限制检查释放逻辑GC 频繁吞吐下降HeapByteBuffer 高频分配改用内存池或线程局部 ByteBuffer你能看到大部分问题并不是 ByteBuffer 本身的 bug而是我们使用索引时状态混乱导致的。真正动手调这个问题的最好手段就是加日志把每次 flip、compact、getInt 之后的 position 和 limit 打出来。等你能像我一样在脑子里模拟这些索引的移动绝大部分收发数据的疑难杂症都能轻松定位。最后分享一个小技巧。调试 ByteBuffer 相关代码时我习惯在 decode 的核心入口临时用buffer.duplicate()拿到一个共享内容的副本再在副本上做 peek 操作比如提前看看 length 字段是多少但不动主 buffer 的 position 和 limit。这个技巧在排查“少读了 4 字节”或者“多读了 2 字节”这种问题时异常好用。8. 扩展一步从 ByteBuffer 到 Netty ByteBuf搞定原生 ByteBuffer 之后我强烈建议你去用一下 Netty 的 ByteBuf。倒不是说 ByteBuf 比 ByteBuffer 高级多少而是你会发现它针对我们前面遇到的痛点做了不少改进。比如 ByteBuf 拆分了 readerIndex 和 writerIndex你不再需要手动 flip 和 compact。它天然知道哪些数据是可读的哪些位置可以继续写。每当你读完一部分数据只需要discardReadBytes()把已读区域释放出来或者干脆不释放等写入指针到头了再统一处理。更关键的是ByteBuf 支持readSlice、retainedSlice这种零拷贝视图操作。拆包时你可以直接readerIndex(4).readSlice(length)把消息体作为一个独立的 ByteBuf 切片交给业务层不需要像原生 ByteBuffer 一样必须byte[] body new byte[length]再 get 一次。Netty 的LengthFieldBasedFrameDecoder也是个现成的拆包器配置几个参数就能用maxFrameLength单条消息最大长度。lengthFieldOffset长度字段偏移量。lengthFieldLength长度字段字节数。lengthAdjustment长度字段的值加上这个调整值等于实际消息体长度。initialBytesToStrip解析后跳过的字节数。我印象很深的是有一次处理一个老系统的协议消息头里有 2 字节的版本号然后才是 4 字节长度长度值包含头部自身而不包含版本号。直接用LengthFieldBasedFrameDecoder(1024, 2, 4, 0, 2)就把问题解决了免去了自己写状态机的麻烦。但这里得提醒一句框架能帮你解决 90% 的常规场景剩下 10% 的私有协议、特殊标志位、压缩消息头、多级嵌套长度字段你还是得回到原始 ByteBuffer 自己动手。这也是为什么我在标题里强调“从 ByteBuffer 内存模型出发”的原因——地基不打好上层框架用起来总归有点心虚。我个人在实际操作中的体会是ByteBuffer 这关早晚要过。你可以在 Netty 的封装下开心写业务代码很多年但只要遇到一次跨语言对接、一次私有协议解析、一次堆外内存排查你就会发现之前偷的懒都得加倍还回来。反而是一开始就把 position、limit、flip、compact 吃透的人后面会顺很多。别急拿个小例子反复跑把每一行索引变化都打印出来你也能在一天之内把它彻底拿下。