ByteBuffer flip 怎样区分 flip 与 rewind

ByteBuffer.flip() 适合写完后准备读取：它把 limit 设为调用前的 position，再把 position 归零。rewind() 适合在已有读取边界内从头重读：它只把 position 归零，保持 limit 不变。两者都不会清空字节内容，也不会改变 capacity。

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

使用场景：写完读取与从头重读

假设一个协议处理程序分配了12字节缓冲区，本次只写入3字节消息，然后交给读取逻辑。这个场景需要先把“分配了多少空间”与“本次消息有多少字节”分开。我会优先看有效数据的边界，而不是把两个方法都记成“回到开头”。

另一个场景是读取同一段消息两遍：第一次做业务解析，第二次重新查看已有数据。此时边界本来已经正确，通常只需要重新定位读取位置。本文用原创示例说明选择规则，没有运行代码或宣称某次线上故障已经修复。

候选操作先看 position 和 limit

position 是下次相对读取或写入的位置，limit 是本次允许访问范围的上界，capacity 是容量。对 ByteBuffer 而言，这些位置按字节计算。应满足 position 不大于 limit，limit 不大于 capacity。

图中 ByteBuffer、position、limit、capacity、有效数据、容量尾部六个节点描述状态与内容两层信息。缓冲区持有三个状态字段；有效数据与 limit 的业务约定有关，容量尾部仍属于分配空间。调用位置方法不会替应用识别消息格式。

两个方法都会丢弃 mark，因此不能依赖它们保留之前设置的 reset 回退点。这里所说的读写模式，是对位置与边界的使用习惯，不是对象被改成只读或可写权限。

用同一个缓冲区比较两种选择

import java.nio.ByteBuffer;
import java.nio.charset.StandardCharsets;

public class BufferChoice {
    public static void main(String[] args) {
        ByteBuffer buffer = ByteBuffer.allocate(12);
        buffer.put("OK!".getBytes(StandardCharsets.US_ASCII));

        // 写入三个字节后，flip 将可读上界设为写入结束位置
        buffer.flip();
        byte[] first = new byte[buffer.remaining()];
        buffer.get(first);

        // 已读完但还要重读相同内容：保留 limit，仅将 position 归零
        buffer.rewind();
        byte[] again = new byte[buffer.remaining()];
        buffer.get(again);

        // 展示的是数据内容，不把容量未写满的尾部当成业务消息
        System.out.println(new String(first, StandardCharsets.US_ASCII));
        System.out.println(new String(again, StandardCharsets.US_ASCII));
    }
}

按代码推导，写入 OK! 后 position 为3、limit 为12。调用 flip 后，position 为0、limit 为3；相对 get 读完三个字节后 position 为3。接着 rewind 保留 limit=3，并将 position 设为0，因此仍只会重新读取这三个字节。这里列的是示例状态推导，不是实际运行输出。

图中 flip、rewind、position、limit、已写范围、既有读取范围六个节点绑定本节解释。flip 关联 position 和 limit，用已写范围解释其用途；rewind 关联 position，并以不改变 limit 的方式保留既有读取范围。它们表达的是方法契约，不是两条可互换的执行路径。

若在最初写入3字节之后直接 rewind，limit 仍是12。此时按 remaining 读取，就可能把未属于本次消息的容量尾部也当成数据。对于新分配缓冲区，那些位置初始为零；对于复用缓冲区，它们还可能保留历史内容。问题在边界，不在字符编码。

哪些情况不适合再次 flip

如果已经 flip 并且尚未读取，position 为0，此时再 flip 会把 limit 设为0，读取范围就变空了。所以不能把 flip 当成幂等的“确保可读”方法。调用前应知道当前位置代表已写长度还是已读进度。

只读了一部分就再次 flip，会用当前读取位置重新设置上界，并回到开头。这通常不是“继续读取剩余数据”所需的动作。需要继续读取就使用当前 position；需要重读整个既有范围再考虑 rewind；需要保留未消费数据并继续写入，应另行理解 compact 的约定。

已经有正确边界的包装缓冲区也不应机械 flip。比如直接包装一个完整字节数组时，它已经具有可访问范围；调用前仍要判断数据和 position 的含义。我的选择标准是“是否需要重设上界”，而不是“上一行有没有 put”。

把选择规则整理成决策表

rewind 会擦掉数据吗？不会，它调整位置。clear 也不代表把底层字节全部填零，方法名不能代替内容清理语义。

flip 会改变字节序吗？不会。字节序与多字节数值读写有关，和本次 position、limit 调整是不同问题。

能让多个线程各自 rewind 吗？缓冲区不自动提供并发安全。共享内容与位置状态需要明确的同步或视图设计，不能用位置方法代替线程协调。

适合 flip 的场景是在调用前就知道 position 表示本次写入结束；适合 rewind 的场景是 limit 已经正确，只想重读。把这两个前提写清楚，代码比单纯背方法名更容易维护。

Buffer方法契约：https://docs.oracle.com/en/java/javase/25/docs/api/java.base/java/nio/Buffer.html

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