flip()必须在read前调用，因其将position重置为0、limit设为原position值，使get()能从头读取已写数据；compact()用于未读完即需续写的场景，将未读数据前移并调整position和limit。
flip() 是读写模式切换的强制开关，compact() 是读写未完成时的续写保底方案；不调用 flip() 就读不到刚写的数据，不理解 compact() 的移动逻辑就容易丢数据或越界。
flip() 为什么必须在 read 前调用
ByteBuffer 写入后 position 指向末尾（比如写了 8 字节，position=8），但 limit 仍为 capacity（比如 10）。此时直接 get() 会从 position=8 开始读，超出有效数据范围，抛 BufferUnderflowException。
调用 flip() 后：
– position 被重置为 0（读起点）
– limit 被设为原 position 值（即 8，表示最多可读 8 字节）
– 这样 get() 才能从头读出全部已写数据
常见错误现象：
– 读出来全是 0 或乱码
– hasRemaining() 返回 false 却没读到任何数据
– 明明 put() 成功了，get() 却报异常
compact() 解决的是“没读完就要再写”的场景
典型于网络 I/O：一次 write() 可能只发出部分数据（比如 buffer 里有 10 字节，但只发出去 3 字节），剩下 7 字节还在 buffer 里，且 position=3。这时不能 clear()（会丢掉那 7 字节），也不能直接 put()（会覆盖未读数据）。
compact() 的实际动作：
– 把 position 到 limit 之间的未读数据（即下标 3~9 的 7 字节）复制到开头（下标 0~6）
– position 设为 7（指向新数据末尾后一位）
– limit 恢复为 capacity（比如 10）
– buffer 进入可追加写的写模式，且保留了未发送数据
注意点：
– compact() 不重置 mark
– 它不会清空已读区域（0~2），只是把剩余数据“前移”
– 如果你误在 full-read 后调用 compact()，会把整段数据白挪一遍，浪费 CPU
clear() 和 compact() 选哪个，取决于是否还有未读数据
二者都用于切回写模式，但语义完全不同：
– clear()：我已完整处理完所有数据，现在要全新写入 → position=0, limit=capacity
– compact()：我只处理了一部分，剩下的还要接着用 → position=未读字节数, limit=capacity
使用场景判断清单：
– 服务端一次性响应固定小包（如 HTTP 200 OK）→ 用 clear()
– 客户端流式上传大文件，每次 write 可能只刷出部分 buffer → 必须用 compact()
– 使用 SocketChannel.write(buf) 返回值小于 buf.remaining() → 下一步必须 compact()，不能 clear()
一个典型循环结构：
while (buf.hasRemaining()) {<br> int written = channel.write(buf);<br> if (written == 0) break; // 暂不可写<br> if (written buf.compact(); // 关键：只写了一部分，压缩剩余<br> break;<br> }<br>}<br>if (!buf.hasRemaining()) buf.clear();
rewind() 和 flip() 容易混淆，但用途截然不同
rewind() 只是把 position 设回 0，limit 不变。它不改变读写语义，常用于“重读已写内容”，比如校验、调试、或反复解析同一段 buffer。
而 flip() 是读写协议的一部分：它把当前写边界变成读上限，并重置读起点。没有这一步，NIO 的读写状态机就断了。
容易踩的坑：
– 把 rewind() 当 flip() 用 → limit 还是 capacity，读的时候会越界
– 在未写满 buffer 时调用 flip() → limit 被设成较小值，后续 get() 只能读那么长，但你以为还有更多
– 多线程共享一个 ByteBuffer 却没同步 flip() / compact() 调用顺序 → position/limit 状态错乱，数据错位
真正难的不是记住每个方法干了什么，而是每次调用前问自己一句：此刻 buffer 里哪些字节是“已确认处理完”的，哪些是“还赖着没走”的——position 和 limit 的数值，永远只是这个判断的结果快照。
