Java ByteBuffer duplicate 和 slice 修改数据有什么区别

Java ByteBuffer 的 duplicate() 和 slice() 都不会复制底层字节，修改任一视图的内容，另一视图都能看到。真正的区别在于“观察哪一段数据”和“是否保留原边界”：duplicate() 复制当前 buffer 的 capacity、position、limit、mark 状态；slice() 从当前 position 开始，只把 remaining 区间映射成一个 position 为 0 的新 buffer。

官方文档：https://docs.oracle.com/en/java/javase/26/docs/api/java.base/java/nio/ByteBuffer.html

先看共享内容和独立状态

下面的代码把 position 推进到 2，再分别创建两种视图。它展示的是 API 语义示意，不是截图或运行证据。

import java.nio.ByteBuffer;
import java.nio.ByteOrder;

public class BufferViewDemo {
    public static void main(String[] args) {
        // 准备一段可写内容，并把当前位置推进到第三个字节
        ByteBuffer source = ByteBuffer.allocate(8);
        source.put(new byte[]{10, 20, 30, 40, 50, 60, 70, 80});
        source.position(2).limit(6);

        // duplicate 保留 source 的 capacity、position 和 limit
        ByteBuffer duplicate = source.duplicate();
        // slice 只映射 source 当前 position 到 limit 的剩余区间
        ByteBuffer slice = source.slice();

        // 视图状态独立：推进 duplicate 不会推进 source 或 slice
        duplicate.get();
        // 内容仍共享：slice 的相对下标 0 对应 source 的绝对下标 2
        slice.put(0, (byte) 99);

        System.out.println(source.get(2));       // 示意输出：99
        System.out.println(duplicate.position()); // 示意输出：3
        System.out.println(slice.position());     // 示意输出：0
    }
}

duplicate() 适合保留完整边界的并行读取

duplicate() 新建的 buffer 仍然面对原来的 capacity 和 limit，只是游标状态单独保存。典型场景是同一帧网络数据既要被协议解析器读取，又要被日志或校验逻辑再次读取：先 duplicate，再让每个消费者推进自己的 position，避免互相影响。

要注意字节序。Java SE 26 文档规定，duplicate() 返回视图的 byte order 为 BIG_ENDIAN。即使原 buffer 之前调用过 order(ByteOrder.LITTLE_ENDIAN)，也不要把这个状态当作业务契约；解析多字节字段时在新视图上明确设置：

// 解析协议字段前显式声明字节序，避免视图默认值造成误读
ByteBuffer packetView = source.duplicate().order(ByteOrder.LITTLE_ENDIAN);
if (packetView.remaining() >= Integer.BYTES) {
    int length = packetView.getInt();
    // 业务代码应继续检查 length 是否落在协议允许的范围内
}

slice() 适合把当前剩余区间交给下游

slice() 的新 buffer position 为 0，capacity 和 limit 等于创建时的 remaining。假设 source 的 position 是 2、limit 是 6，那么 slice 的下标 0、1、2、3 对应 source 的下标 2、3、4、5。下游只看这 4 个字节，不需要知道前面已经消费了多少数据。

这使它很适合分段写入、协议 payload、文件窗口或把 header 与 body 分开交给不同函数。边界也更安全：下游调用 slice.get() 时最多只能读这一段，不能越过创建时的 limit 访问 source 的其他内容。

选择清单与常见坑

最容易误判的是把“视图独立”理解成“数据独立”。它只表示游标和边界独立，不表示字节副本独立；如果调用方需要回滚后仍保留原始内容，就必须显式复制。另一个坑是先改变 source 的 position、limit 再 slice：slice 只记录创建瞬间的窗口，后续 source 的游标变化不会自动扩大它。

相关问题

修改 slice 会不会修改原 ByteBuffer？

会。只要不是只读 buffer，slice 与原 buffer 共享内容；但两者 position、limit、mark 独立。

duplicate 能代替深拷贝吗？

不能。duplicate 只复制状态视图，底层字节仍是同一份；需要隔离写入时应显式复制数据。

为什么 slice 的 position 总是从 0 开始？

它把原 buffer 当前 position 到 limit 的窗口重新映射为下游自己的地址空间，调用方不必携带原始绝对下标。