netty 不使用 ringbuffer，其零拷贝核心是 fileregion + sendfile()、compositebytebuf/slice 内存视图及 pooledbytebufallocator 内存池三者协同：前者实现文件级零拷贝，中者实现协议层零拷贝，后者解决分配开销。
Netty 本身没有环形缓冲区（RingBuffer）设计
Netty 不使用 RingBuffer，这是常见误解。RingBuffer 是 Disruptor、LMAX 等框架的典型结构，用于无锁生产者-消费者通信；而 Netty 的 I/O 底层依赖 JDK NIO 的 Selector + 操作系统内核的就绪事件通知机制，并不维护用户态 RingBuffer。网卡硬件层确实有 RingBuffer（DMA 环形队列），但那是 Linux 内核和驱动管理的，Netty 无法直接操作或“利用”它做零拷贝数据处理。
真正起作用的是 FileRegion + sendfile() 系统调用
Netty 实现文件级零拷贝的核心路径是：FileRegion → FileChannel.transferTo() → Linux sendfile() 系统调用。这个链路绕过了 JVM 堆内存和用户空间缓冲区，让数据从磁盘页缓存（page cache）直接送入 socket 发送缓冲区。
- 必须用
new DefaultFileRegion(fileChannel, position, count)包装，不能用普通ByteBuf读取再 write - 目标
Channel必须是SocketChannel（且底层支持transferTo），不能是EmbeddedChannel或自定义伪 Channel - Linux 内核需 ≥ 2.4，且文件需在 ext4/xfs 等支持 direct I/O 的文件系统上（否则可能 fallback 到普通 read/write）
- 注意
FileRegion是引用计数对象，需手动ReferenceCountUtil.release()，否则泄漏
CompositeByteBuf 和 slice 才是内存层零拷贝主力
当你要拼接协议头+体、或拆分粘包消息时，CompositeByteBuf 和 slice() 才是你日常能稳定用上的零拷贝手段——它们不复制字节，只共享底层存储并维护独立指针。
-
CompositeByteBuf composite = Unpooled.compositeBuffer().addComponents(true, header, body)：true表示自动释放子 buf，避免手动管理 -
ByteBuf msg = buffer.slice(0, length)返回逻辑视图，buffer被 release 后所有 slice 失效——这点极易踩坑 - 切片后若需长期持有，必须调用
.retain()；不再需要时统一.release()，不能只释放 slice - 不要对
CompositeByteBuf调用array()或hasArray()，它没有 backing array
内存池 + 直接内存才是高吞吐的根基，不是零拷贝本身
零拷贝解决的是“拷贝开销”，但吞吐瓶颈常在内存分配/回收频率。启用 PooledByteBufAllocator 后，ByteBuf 从线程本地池中复用，避免频繁 GC；配合 .directBuffer() 使用堆外内存，减少 JVM 堆压力和 GC 停顿。
- 务必在
Bootstrap中设置：.childOption(ChannelOption.ALLOCATOR, PooledByteBufAllocator.DEFAULT) - 禁用
PooledByteBufAllocator（如用Unpooled）会导致每秒万级小对象分配，P99 延迟飙升 - 堆外内存泄漏难排查，建议上线前加 JVM 参数：
-Dio.netty.leakDetectionLevel=PARANOID -
AdaptiveRecvByteBufAllocator动态调整接收缓冲区大小，比固定ALLOCATOR更适应流量波动
真正难的是组合：FileRegion 用对了才能发挥 sendfile 效果，CompositeByteBuf 和 slice 用错一次就会引发内存泄漏或越界读，而内存池一旦关掉，零拷贝带来的收益会被 GC 吞得一干二净。三者缺一不可，且必须按场景选型——传大文件用 FileRegion，协议编解码用 Composite/slice，长连接高并发必开内存池。
