Netty ByteBuf 相比 ByteBuffer 有什么优势？

简化版

Netty 的 ByteBuf 相比 JDK 的 ByteBuffer 更适合网络编程，优势有：① 读写指针分离（readerIndex + writerIndex，不用像 ByteBuffer 那样在读写模式间 flip()，协议解析更直观、少踩坑）；② 容量可动态扩展（ByteBuffer 容量固定，不够要手动新建复制）；③ 支持池化（内存复用）和堆外内存（高吞吐场景减少分配和 GC）；④ API 更友好（丰富的读写方法、slice/duplicate 视图）。代价是：池化 + 堆外内存靠引用计数管理，用不当会内存泄漏——「会用 ByteBuf」本质是「会管理数据边界和生命周期」。

详细版

ByteBuf vs ByteBuffer：

维度	JDK ByteBuffer	Netty ByteBuf
读写指针	一个 position，读写切换要 `flip()`	readerIndex + writerIndex 分离
模式切换	写完 flip、读完 clear/compact（易错）	不需要切换
扩容	容量固定，不够要手动新建复制	可动态扩容
池化	不支持	支持（PooledByteBufAllocator）
堆外内存	支持（DirectByteBuffer）	支持，且配合池化
生命周期	靠 GC	引用计数（需手动 release）

ByteBuf 的三段区域（核心模型）：

+--------+----------------+------------+
| 已读区  |    可读区       |   可写区    |
+--------+----------------+------------+
0    readerIndex     writerIndex    capacity

read  → 推进 readerIndex
write → 推进 writerIndex

完整版教学

一、读写指针分离（最大优势）

JDK ByteBuffer 只有一个 position 指针，用 position/limit 来切换读写模式：写完数据后要调 flip() 切到读模式，读完要 clear() 或 compact()。这个模式切换极易出错——忘了 flip 就读到错误数据，是 NIO 编程的经典坑。

ByteBuf 用两个独立指针：readerIndex（读到哪了）+ writerIndex（写到哪了）。读和写各自推进自己的指针，不需要来回切换模式——写数据推进 writerIndex，读数据推进 readerIndex，可读区和可写区边界一清二楚。这让协议解析（尤其半包、累积解码）更直观、更不易错。

二、可读区和可写区（三段模型）

ByteBuf 内部分三段（要记住这个模型）：

0 ~ readerIndex：已读区域（读过的，可丢弃或复用）。
readerIndex ~ writerIndex：可读区域（有数据待读）。
writerIndex ~ capacity：可写区域（空的，能写入）。

理解这个模型，就能推断行为：read 操作从 readerIndex 读并推进它；write 操作在 writerIndex 写并推进它。readableBytes() = writerIndex - readerIndex（还有多少可读）。这个模型是理解 ByteBuf 所有操作的基础。

0            readerIndex          writerIndex          capacity
| 已读区域   |       可读区域      |       可写区域       |

API 类型	是否移动 readerIndex	是否移动 writerIndex	典型用途
`read*`	是	否	消费一段可读数据
`get*`	否	否	只查看字段，不改变解析进度
`write*`	否	是	追加写入数据
`set*`	否	否	修改指定位置，不改变写入进度

面试讲 ByteBuf，不要只说 API 好用；要把“读写指针分离、三段模型、池化/堆外、引用计数生命周期”连起来讲。

三、容量可扩展

网络消息长度往往不固定（一个请求多大不知道）。ByteBuf 可以按需自动扩容——写入时如果可写区不够，会自动扩大容量。而 JDK ByteBuffer 容量固定，空间不够时要手动新建一个更大的 buffer 再把数据复制过去，样板代码多、易错。Netty 的扩容策略（按一定规则增长）省掉了这些重复代码。

四、堆内和堆外内存

ByteBuf 支持两种内存：

堆内（Heap）ByteBuf：数据在 JVM 堆里，受 GC 管理、访问底层数组方便，但 socket 读写时需要多一次拷贝（从堆内拷到堆外再给内核）。
堆外（Direct）ByteBuf：数据在堆外内存，减少了 socket I/O 的一次拷贝、减轻 GC 压力，但分配和释放成本更敏感（不受 GC 直接管理，靠引用计数）。

高性能网络服务常结合「池化 + 堆外内存」——用池化摊薄堆外内存的分配成本。

五、池化的收益和代价

PooledByteBufAllocator（池化分配器）复用内存块——用完的 ByteBuf 归还到池里，下次分配直接复用，降低了频繁分配/释放的成本和 GC 压力。Netty 默认就用池化分配器。

代价：对象生命周期更复杂——池化的 ByteBuf 用完必须正确归还（release），否则内存块不会回到池里（泄漏）。吞吐越高，池化收益越明显，但泄漏风险也越需要治理（见「引用计数/内存泄漏」专题）。

六、slice、duplicate 和 copy（视图 vs 复制）

ByteBuf 提供几种「派生」方法，区别关键：

slice() / duplicate()：多数情况下共享底层内存，只是创建一个不同的视图（不同的读写指针范围）——性能好（不复制数据）。
copy()：真正复制一份数据，独立的内存。

共享视图性能好，但有陷阱：slice/duplicate 和原 buffer 共享同一块内存和引用计数——如果原 buffer 被 release 了，视图也可能不可用（悬空）。所以用 slice/duplicate 时，retain/release 的关系必须想清楚（谁持有、谁释放）。

七、使用中的红线

ByteBuf 使用的几条红线（都关乎引用计数）：

不要在 release 后继续访问 ByteBuf（内存可能已被回收/复用，会读到脏数据或抛异常）。
跨异步线程传递 ByteBuf 后，要记得 retain（增加引用防止被提前释放）。
异常路径不要漏 release（用 try/finally 保证释放，见相关专题）。
必备习惯：开发/压测时打开 ResourceLeakDetector 泄漏检测、压测时观察 direct memory 增长——提前发现泄漏。

八、常见误区与追问

误区：ByteBuf 只是 ByteBuffer 的 API 包装。 ByteBuf 的核心变化是读写指针分离、容量扩展、池化/堆外内存和引用计数生命周期，不只是方法名更顺手。
误区：slice() 一定会复制数据。 slice() 和 duplicate() 通常是共享底层内存的视图，只有 copy() 才会复制字节。
误区：池化 ByteBuf 靠 GC 自动回收就够了。 池化尤其是堆外 ByteBuf 需要通过引用计数释放，忘记 release() 会让内存无法归还。
追问：read* 和 get* 方法有什么区别？ read* 会推进 readerIndex，表示数据被消费；get* 只是按下标查看，不改变解析进度。
追问：为什么网络 I/O 更常用 Direct ByteBuf？ Socket I/O 最终要和堆外内存交互，Direct ByteBuf 可以减少堆内到堆外的一次复制，并降低大块缓冲对 GC 的压力。
追问：跨线程传递 ByteBuf 为什么通常要 retain()？ 原线程可能先释放 ByteBuf，异步线程稍后再读会遇到引用计数归零；retain() 表示异步线程也持有一份责任，用完再 release()。

九、加强记忆

ByteBuf 比 JDK ByteBuffer 更适合网络：① 读写指针分离（readerIndex+writerIndex，不用 flip() 切模式，协议解析直观少坑）；② 三段模型（已读区/可读区/可写区，read/write 各推进自己指针）；③ 容量可动态扩容（ByteBuffer 固定要手动复制）；④ 支持池化（PooledByteBufAllocator 复用内存降 GC）+ 堆外内存（减少 I/O 拷贝）；⑤ slice/duplicate 共享底层内存的视图（性能好但要理清 retain/release，原 buffer 释放后视图悬空），copy 才真复制。代价：靠引用计数管理生命周期，用不当会内存泄漏（红线：release 后别访问、跨线程传递要 retain、异常路径别漏 release，开泄漏检测 + 盯 direct memory）。核心：会用 ByteBuf = 会管数据边界（三段模型）+ 会管生命周期（引用计数）。

简化版

详细版