flip()是写完转读的唯一安全切换动作：将limit设为当前position、position重置为0，不改变capacity和底层数组，使后续get()能从头读取已写入的全部数据。
flip() 是写完转读的唯一安全切换动作
不调用 flip() 就直接 get()，结果不是读到 0，就是抛 BufferUnderflowException。因为写完后 position 停在数据末尾，limit 还是 capacity，读操作会从末尾开始、一路越界。
flip() 只做两件事：limit = position，然后 position = 0。它不复制、不清空、不改变 capacity，只是“封存当前写入成果”，让后续 get() 能从头读到刚写进去的所有字节。
- 典型场景：用
channel.read(buffer)写入后，必须flip()才能交给decoder或get()解析 - 误用风险：重复调用
flip()会让limit = 0，再读就什么都没有 - 只读
ByteBuffer也能调flip()，但之后调put()会抛ReadOnlyBufferException
compact() 是半包处理时的读写衔接关键
TCP 粘包场景下，一次 read() 可能只收到半个消息。这时你不能 flip()（否则后半截丢了），也不能 clear()（前半截白读了）。compact() 就是为此设计的：把 position 到 limit 之间还没读完的数据，拷贝到缓冲区开头，再把 position 设为已拷贝长度，limit 恢复为 capacity。
- 执行后状态示例：原 buffer 容量 1024，写入 800 字节 →
position=800,limit=1024；读了 500 字节 →position=500,limit=1024；调compact()后 → 前 300 字节移到开头，position=300,limit=1024 - 注意：这是内存拷贝操作，64KB 以上缓冲区频繁调用会影响吞吐，可考虑增大初始容量或改用堆外缓冲区减少 GC 压力
-
compact()后不能立刻get()，得先flip()—— 因为它本质是为“继续写”准备的，不是为读
clear() 和 rewind() 的语义差异常被混淆
clear() 是“全盘重来”：position = 0，limit = capacity，相当于把缓冲区当新分配的一样用，之前所有数据逻辑上丢弃（底层数组不变，但指针已移开）。
rewind() 是“重头再来”：position = 0，limit 不变。适合你刚读了一半又想重读一遍，或者写了一半想检查开头内容。
- 误用案例：读完数据后调
clear()再写，没问题；但如果读完一半发现格式错，想重试解析，该用rewind()，不是clear() -
rewind()不影响limit，所以如果之前没调过flip()，limit还是capacity，rewind()后get()可能读到脏数据 - 三者都不加锁，多线程共享同一个
ByteBuffer时，必须自行同步或改用线程局部实例
实际调试时怎么看指针状态
别靠猜，直接打日志看三个值。JDK 自带的 toString() 输出格式是 java.nio.HeapByteBuffer[pos=0 lim=1024 cap=1024]，一眼就能确认当前模式。
- 写模式特征：
position - 读模式特征：
position ，且limit通常等于上一轮写入长度 - 危险状态：
position == limit时再get()必抛异常；position > limit是非法状态，一般由手动改指针导致 - 建议在关键路径（如
read()后、flip()前、get()循环中）插入System.out.println(buffer)快速定位问题
真正容易被忽略的是：这些指针操作全部不校验业务逻辑。比如 flip() 后 limit 是 0，它不会提醒你“你根本没写入任何数据”；compact() 把未读数据挪到开头，也不会保证那 300 字节恰好是个完整协议帧。边界判断和协议解析，始终得由你自己兜底。
