Java里BufferOverflowExceptionNIO缓冲区溢出运行时异常

BufferOverflowException 并不是 Ja va NIO 里那种需要大惊失色的“报错”。实际上，它更像一个边界哨兵，语气冷静地告诉你：缓冲区已经满员，无法再写入更多数据。这不代表程序崩了，而是状态管理上欠了点火候。

为什么一写就抛这个异常？

说白了，就是 position 已经跑到 limit 前面去了，而你还在调用 put()、putInt() 这些写入方法。NIO 缓冲区里这三兄弟——capacity、limit、position——各有分工：

• capacity：总容量，一开始定好就不再变
• limit：当前可写或可读的上限，注意它不一定是 capacity
• position：下一个操作位置，写入时它会往前跑，直到撞上 limit 为止

一旦 position 和 limit 碰头，你再往里塞数据，这个异常就立刻现身——没有任何通融的余地。

常见踩坑场景

下面这几个坑，看起来都不复杂，但越是常见的 I/O 操作，越容易反复踩进去，尤其是在处理协议解析或循环读写的时候：

• SocketChannel.read(buffer) 读完数据后，忘了调用 flip() 就急着拿去 write()，或者继续 read()。这时候 buffer 还处在“写模式”，limit 虽然等于 capacity，但 position 已经往前推了，后续 put 很容易越界。
• 多次 clear() 之后重复写入，却忘了检查 remaining()——尤其是在循环处理分片数据时，很容易一不留神就写满了。
• 用 slice() 或 duplicate() 创建子缓冲区后，误以为它的 limit 还是原 buffer 的 capacity，结果实际可用空间远小于预期。
• 网络包的头部声明 payload 长度为 2048，但你只分配了 1024 的 ByteBuffer，还没做长度校验就直接调用 buffer.put()。

真正有效的应对方式

千万别想着靠 try-catch 去抓这个异常来控制流程——那是一条标准反模式。正确做法是把检查做在前面，把状态理清楚：

• 写入前一定要查一下：if (buffer.remaining() >= data.length)，不够就直接拒绝写入，或者及时扩容。
• 写完数据立刻 flip()，为接下来的读操作做好准备；读完之后根据需求，要么 clear()（全部重用），要么 compact()（保留未读部分）。
• 接收网络数据时，先读固定长度的头部（比如 4 字节的长度字段），校验这个长度 ≤ buffer.remaining()，然后再去读 body 部分。
• 尽量不要手动去修改 position 和 limit，优先用 flip()、clear()、compact() 这些标准方法来切换状态，省心又安全。

要不要加大缓冲区？

把 capacity 增大确实能缓解问题，但它解决不了状态管理上的漏洞。打个比方，你就算 allocate(8192)，如果反复 flip 忘记重置，或者不检查 remaining()，该溢出还是溢出。更稳妥的做法是组合拳：

• 根据业务中最大单个包的大小来预估 buffer 的容量。
• 遇到超大包，启用分片处理，或者用 ByteArrayOutputStream 配合 ByteBuffer.wrap() 做动态扩容。
• 在关键路径上加上断言：assert buffer.hasRemaining() : "buffer full before write"——让问题在开发阶段就暴露出来。