Java NIO缓冲区溢出预防详解

<p>BufferOverflowException 是 ByteBuffer 写入超限异常，非 JVM 内存溢出；它在 put() 超过 remaining()（即 limit - position）时立即抛出，与 capacity 无关，常见于未检查剩余空间、忘记 flip/compact 或直接分配过小缓冲区。</p>

BufferOverflowException 是写进 ByteBuffer 时超限，不是内存溢出

这个异常和 JVM 堆内存溢出（OutOfMemoryError）完全无关，它只发生在 NIO 的 ByteBuffer 写入操作中——当你试图往一个已满的缓冲区继续 put()，或者 put() 超过剩余空间（remaining()），就会立刻抛出 BufferOverflowException。

常见错误现象：

• 调用 buffer.put(byteArray) 时没检查 buffer.remaining()，数组长度大于剩余空间
• 循环写入时忘了调用 flip() 或 compact()，导致后续写入始终在“已满”状态
• 用 allocateDirect() 分配了小缓冲区（比如 1KB），但实际要写入几 MB 数据，却没做分块处理

写入前必须检查 remaining()，不能只看 capacity()

capacity() 是缓冲区总大小，limit() 是当前可写/可读边界，position() 是下一次操作位置——真正决定还能写多少的是 remaining() == limit() - position()。很多同学误以为“只要没超 capacity 就安全”，结果在 flip() 后 position 回到 0、limit 缩到之前写入长度，此时 remaining() 可能只剩 0。

实操建议：

• 每次 put() 前加断言：if (buffer.remaining() < data.length) throw new IllegalStateException("buffer full");
• 批量写入推荐用 buffer.put(src, offset, length)，并确保 length <= buffer.remaining()
• 如果数据长度不确定，优先用 buffer.hasRemaining() 控制循环，而不是硬算

避免手动管理 position 和 limit：用 flip() / compact() / clear() 的真实含义

这三个方法不是“清空数据”，而是重置元数据指针，误用会直接导致 BufferOverflowException 或数据覆盖：

• flip()：把 limit 设为当前 position，再把 position 设为 0 —— 用于写完后切到读模式；之后若继续写，必须先 compact() 或 clear()
• compact()：把未读数据移到开头，position 设为已复制长度，limit 设为 capacity() —— 适合“边读边写”的流式场景
• clear()：重置 position=0、limit=capacity，丢弃所有读写状态 —— 适合完全重用缓冲区，但会丢失未消费数据

典型坑：flip() 后没 compact() 就再次 put()，此时 position == limit，remaining() 为 0，必然抛异常。

大块数据写入必须分片，别指望单个 ByteBuffer 吃下全部

NIO 缓冲区不是动态扩容容器。即使你用 allocate(1024 * 1024) 分配了 1MB，遇到 5MB 数据也得自己拆。不拆的后果不是慢，是直接崩在第一个 put()。

实操建议：

• 封装写入逻辑，例如：writeFully(ByteBuffer buf, byte[] data) 内部循环 put() 并自动 compact()
• 配合通道写入时，用 channel.write(buf) 返回值判断是否写完（返回实际字节数），未写完则继续
• 对网络或文件 I/O，优先复用固定大小缓冲区（如 8KB），而非按需分配——减少 GC 和系统调用开销

容易被忽略的一点：ByteBuffer.array() 返回的底层数组长度恒等于 capacity()，但 arrayOffset() 和 limit() 才决定有效范围；直接拿 array() 当普通数组用，可能读到脏数据或越界。