ByteBuf 的读写指针更省心，因其分离 readerIndex 和 writerIndex，避免 ByteBuffer 单 position 导致的 flip/clear 状态混乱；默认自动扩容且透明处理容量不足；slice() 与 retainedSlice() 明确区分共享视图与引用计数，配合 CompositeByteBuf 实现安全零拷贝；需显式 release() 防堆外内存泄漏。
ByteBuf 的读写指针为什么比 ByteBuffer 更省心
Java NIO 的 ByteBuffer 用起来总得手动调用 flip()、rewind()、clear()，稍不注意就 BufferUnderflowException 或写不进数据。根本原因是它只有一个指针（position），读写共用，语义模糊。
ByteBuf 直接拆成两个：一个 readerIndex，一个 writerIndex，读写互不干扰。你往里写多少，writerIndex 就涨多少；从哪开始读，readerIndex 自己记着——不用翻来覆去重置状态。
- 写完直接读？不用
flip()，readXXX()方法自动从当前readerIndex开始取 - 想跳过前 4 字节再读？
skipBytes(4)，只动readerIndex，writerIndex不受影响 - 需要复用同一段缓冲区做多次读写？
resetReaderIndex()/resetWriterIndex()各自回退，互不绑架
自动扩容怎么避免“写到一半抛 OutOfBoundsException”
ByteBuffer 是固定容量，put() 超了直接 BufferOverflowException，你还得自己 catch + allocate + copy，逻辑缠绕。
ByteBuf 默认是可扩容的（比如 Unpooled.buffer() 创建的），写入时发现不够，它悄悄分配新内存、拷贝旧数据、更新指针——对上层代码完全透明。
立即学习“Java免费学习笔记（深入）”；
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- 仅当使用
Unpooled.directBuffer(int initialCapacity, int maxCapacity)且明确设了maxCapacity时，才可能触发IndexOutOfBoundsException - 普通场景下，
writeBytes(byte[])、writeInt()等方法都不用提前 check 容量 - 但要注意：扩容有开销，高频小写入可能引发频繁 realloc；若确定大小，用
Unpooled.wrappedBuffer()或预设足够容量更稳
CompositeByteBuf 和 slice() 怎么避开共享内存误改坑
ByteBuffer 的 slice() 返回共享底层数组的新 buffer，改子 buffer 的内容会波及原 buffer —— 很多 NIO 框架因此出过诡异 bug。
ByteBuf 的 slice() 和 retainedSlice() 行为更可控，尤其配合 CompositeByteBuf 做零拷贝聚合时：
-
slice()是轻量视图，不增加引用计数；原ByteBuf被release()后，slice 会失效（访问抛IllegalReferenceCountException） - 要长期持有切片？必须用
retainedSlice()，它会主动retain()底层资源 -
CompositeByteBuf可以把多个ByteBuf逻辑拼成一个，writeBytes(composite)不复制数据，但你要确保各 component 生命周期合理，别提前release()
为什么 release() 忘记调用会导致堆外内存泄漏
ByteBuffer 用的是 JVM 堆内内存或 Cleaner 回收堆外内存，开发者基本不管释放；ByteBuf（尤其是 PooledByteBuf）依赖显式引用计数，漏掉 release() 就等于内存永远不还池子。
Netty 的 ResourceLeakDetector 默认开启（级别 LEVEL_ADVANCED），会在 GC 时扫描未释放的 buffer 并打印警告，但只报“疑似泄漏”，不精确到行号。
- 最稳妥做法：在
ChannelHandler的channelRead()末尾调用buf.release()，或用ReferenceCountUtil.release()防空指针 - 如果要把 buffer 传给下游 handler 处理，记得用
buf.retain()增加计数，避免上游 release 后下游访问失效 -
ByteBufAllocator的池化策略（PooledvsUnpooled）会影响泄漏后果：池化泄漏会快速耗尽 chunk，非池化只是堆外内存缓慢增长
读写指针分离和自动扩容看着是便利性改进，实际改变了整个 buffer 生命周期的控制粒度——用错一次 release()，或者误信 slice() 是深拷贝，问题就会在高负载时集中爆发。
