ByteBuffer写完后读不到数据是因为未调用flip()：写模式下position停在末尾、limit=capacity，flip()将position设为新limit并归零position，使读操作覆盖已写区域。
ByteBuffer写完后读不到数据？一定是没调用flip()
写完数据后直接get()或get(byte[])返回0或抛BufferUnderflowException，本质是position没重置、limit没收缩。写模式下limit等于capacity，position停在写入末尾；不flip()，读操作就从“末尾”开始读，自然读不到东西。
正确流程只有两步：put() → flip() → get()。其中flip()干三件事：把当前position设为新的limit（即有效数据长度），把position归零，clear mark（如果有的话）。
-
flip()后position=0，limit=原position，正好覆盖已写区域 - 多次
flip()无害，但反复flip()→get()→flip()会导致读取范围不断缩小（因为每次get()移动position，下次flip()的limit就变小） - 如果写入中途中断（比如只put了3个字节），
flip()仍以当前position为准，不会自动补零或截断
想重复写入新数据，该用clear()还是compact()？
clear()是重置缓冲区最常用的操作，但它不丢数据——只是把position设为0、limit设为capacity、mark设为-1。底层array()或堆外内存里的字节全还在，只是后续put()会从头覆盖。
真正要保留未读完的数据并追加写，得用compact()：它把position到limit之间的未读数据移到buffer开头，然后position设为已复制长度，limit设为capacity。适合“边读边写”的流式场景（比如网络收包后处理一部分，剩下留着和下次数据拼接）。
立即学习“Java免费学习笔记（深入）”；
将后端 Java 接口文档转换为前端 TypeScript 类型定义（interface / type）。输入：飞书文档、Spring Boot 接口文档、Swagger/OpenAPI、手写 API 文档等。输出：包含请求参数与响应结果的 .md 文件，含完整 JSDoc 注释。触发关键词：Java 转 TS、接口转换、生成前端类型、接口文档转 TypeScript、DTO/VO/BO 转 interface、后端文档转前端类型、生成接口类型、类型定义生成。
-
clear()：适合“一次写完→读完→清空→再写”的循环，比如HTTP响应体构造 -
compact()：适合“读一部分→处理→剩余数据暂存→等下次数据来拼接”，比如TCP粘包处理 -
rewind()不能代替clear()：它只重置position=0，limit不变，无法释放写空间
为什么flip()之后再put()会抛BufferOverflowException？
因为flip()后limit被设为之前写入的长度，此时buffer逻辑上是“只读状态”。再调put()就会尝试往[0, limit)区间写，但position从0开始递增，很快超过limit。
典型误操作：写→flip→读一部分→想继续写新数据→直接put。这时必须先clear()（丢弃所有旧数据）或compact()（保留未读部分），才能恢复写能力。
- 错误链：
put(3); flip(); get(1); put(1);→ 第二个put()触发异常 - 修复方式取决于意图：想丢弃全部就
clear()；想保留未读的2字节就compact()（此时buffer前2字节是原数据，position=2，可继续put） - 没有“读写双工”模式：ByteBuffer始终是单向状态机，读写切换必须靠
flip()/clear()/compact()
堆内vs堆外ByteBuffer对flip()/clear()有影响吗？
没有。这两个方法只操作buffer的四个元数据字段（mark、position、limit、capacity），和底层内存是否在堆内无关。堆外buffer（ByteBuffer.allocateDirect()）执行flip()一样快，也不触发GC。
但要注意：堆外内存的生命周期不由JVM自动管理，即使buffer对象被回收，内存可能滞留。不过这和flip()无关，属于Cleaner机制范畴。
- 所有ByteBuffer子类（heap/direct/mapped）都继承同一套状态逻辑
- 唯一影响性能的点是：direct buffer的
get()/put()涉及JNI调用，比heap buffer慢，但flip()/clear()本身开销可忽略 - 别在循环里反复
allocateDirect()+clear()，容易触发系统级内存分配失败，应复用buffer
