slice()创建的是可读字节范围的独立视图，新缓冲区position恒为0、capacity和limit等于原缓冲区remaining()，底层数据数组完全共享，索引状态互不影响，但修改共享内存内容双方立即可见。
slice() 创建的是可读字节范围的独立视图
调用 slice() 时，新 ByteBuffer 的底层数据数组与原缓冲区完全共享，但它的逻辑边界被严格限定在 position 到 limit 之间（即 remaining() 字节数）。这意味着：
- 新缓冲区的
position总是 0，capacity和limit都等于原缓冲区的remaining() - 对任一缓冲区的
put()或get()操作，只要落在共享内存区间内，另一方立刻可见 - 两个缓冲区的索引状态（
position、limit、mark）互不影响；修改原缓冲区的position不会改变 slice 出来的缓冲区内容起始点 - 如果原缓冲区是只读（
isReadOnly()返回 true）或堆外（isDirect()为 true），slice 出来的缓冲区也会继承这些属性
典型误用：在调用 slice() 前忘了先 flip()，导致 slice 出来的是从当前 position 开始的“空余空间”，而非已写入的有效数据。
duplicate() 是全量共享副本，但索引各自独立
duplicate() 返回的新 ByteBuffer 与原缓冲区共享**整个底层数组**（从 0 到 capacity），且所有元数据（capacity、limit、position、mark）初始值都一致。但它不是拷贝数据，只是复制了缓冲区的“描述信息”。
- 修改任一缓冲区的
position或limit，不会影响另一个——这是和slice()相同的关键点 - 但两者操作同一内存地址：往 duplicate 出来的缓冲区
put(0, (byte)99)，原缓冲区索引 0 处的值也会变成 99 - 如果原缓冲区是只读，duplicate 出来的也只读；如果是 direct，duplicate 出来的也是 direct
- 注意：
duplicate()不会重置原缓冲区的position，也不触发任何引用计数变更（它不涉及 Netty 的ByteBuf）
常见陷阱：误以为 duplicate() 是安全的“浅拷贝”，结果在多线程中让两个 Handler 同时操作同一块内存，引发数据竞争。
Netty 的 ByteBuf.slice() 行为更聚焦于可读区域
Netty 的 ByteBuf.slice() 语义比 JDK ByteBuffer.slice() 更明确：它只切出 [readerIndex, writerIndex) 区间，也就是“当前可读字节”部分，且新 ByteBuf 的 readerIndex 固定为 0，writerIndex = readableBytes()。
- 这个 slice 出来的
ByteBuf仍受引用计数约束；它不调用retain()，所以若原ByteBuf被release()，slice 视图可能失效（访问会抛IllegalReferenceCountException） - 它不改变原
ByteBuf的readerIndex或writerIndex，这点和 JDK 的slice()一致 - 如果你需要脱离原
ByteBuf生命周期的副本，必须显式调用copy()，而不是slice()
真实踩坑场景：在 ChannelHandler 中对入站 ByteBuf 调用 slice() 后传给业务线程处理，但主线程紧接着就 release() 了原 ByteBuf，导致业务线程读取时直接崩溃。
什么时候该用 slice()，什么时候必须 copy()
核心判断依据就一条：是否允许数据修改穿透到原始缓冲区，以及是否需要脱离其生命周期。
- 用
slice()：协议解析时拆分 header/body（需保持零拷贝、且生命周期一致）、日志模块只读查看某段内容、构建复合消息视图 - 必须用
copy()（Netty）或ByteBuffer.allocate().put(src).flip()（JDK）：跨线程传递、缓存部分内容、需要修改副本而不影响源、或者原缓冲区即将释放 - 慎用
duplicate()：仅适合临时做索引遍历（比如先 scan 再 reset），不适合长期持有或跨作用域传递；它最容易掩盖并发问题
最常被忽略的一点：JDK 的 ByteBuffer 没有引用计数，所以 slice() 和 duplicate() 的“共享”是纯粹内存层面的；而 Netty 的 ByteBuf.slice() 共享内存的同时还共享引用计数上下文——这使得“视图隔离”在语义上更脆弱，也更需要开发者主动管理生命周期。
