BufferOverflowException是Java NIO缓冲区状态管理失当的明确信号，源于position≥limit时仍调用put()，需写前校验remaining()、写后flip()、读后clear()/compact()并配合两级长度校验。
Java 中字节流读写本身不会直接导致传统意义上的“缓冲区溢出漏洞”（如 C 语言中内存越界写入），但 ByteBuffer 的误用、缓冲区容量不足或状态管理错误 会引发 BufferOverflowException，尤其在 NIO 场景下非常典型。这不是 JVM 内存安全机制失效，而是逻辑层面的缓冲区使用不当。
检查并规范 ByteBuffer 的读写模式切换
ByteBuffer 的 position、limit、capacity 三者关系决定是否能安全读写。常见错误是写完没 flip 就读，或读完没 clear/compact 就继续写。
- 写完必须 flip() 才能读：flip() 把 limit 设为当前 position，position 归零——此时缓冲区进入“只读准备态”。若之后调用 put()，必然抛 BufferOverflowException
- 读完要 clear() 或 compact()：clear() 重置 position=0、limit=capacity，适合丢弃全部旧数据后写新内容；compact() 把未读数据移到开头、position 设在末尾、limit=capacity，适合“边读边写”的流式场景（如解析不完整包）
- 避免在 OP_READ 回调中无条件反复 channel.read(buffer)：每次 read 前应先检查 buffer.hasRemaining()，否则可能向已满缓冲区继续写入
合理设置缓冲区容量并配合分包处理
缓冲区大小不是越大越好，也不是越小越安全，关键在于匹配协议预期和网络行为。
- 若用
ByteBuffer.allocate(1024)接收不定长消息，而实际单条消息可能达 2MB，就必然溢出——这时应启用分包逻辑（如自定义长度头 + 循环 read + 累积缓冲） - 对于 Netty 或自建 NIO 服务，接收缓冲区建议 ≥ 最大单帧消息长度；若无法预估，可结合
compact()和动态扩容（如用ByteBuffer.wrap(new byte[...])替换旧 buffer） - 注意：SocketChannel.write() 若传入的是只读缓冲区（
asReadOnlyBuffer()），某些 JDK 版本会抛 BufferOverflowException 而非更明确的 ReadOnlyBufferException
优先使用带边界控制的高级 I/O 工具
非必要不裸用 ByteBuffer；对文件或普通流操作，应优先选用封装完善的缓冲流。
- 用
BufferedInputStream / BufferedOutputStream处理文件：它们内部有固定大小缓冲区（默认 8192 字节），自动处理分块读写，无需手动管理 position/limit - 用
Files.copy()或Files.newInputStream()配合 try-with-resources，避免手动分配和释放缓冲区 - 处理文本时用
BufferedReader.readLine()，它按行截断、自动跳过越界风险，比手动 byte[] + String 构造更安全
警惕直接缓冲区与堆外内存的隐性限制
使用 ByteBuffer.allocateDirect() 时，虽不占堆内存，但受 JVM 直接内存上限（-XX:MaxDirectMemorySize）约束。超限会触发 OutOfMemoryError: Direct buffer memory，表现类似溢出。
- 监控直接内存使用：可通过
BufferPoolMXBean获取 NIO 缓冲池统计信息 - 及时释放不再使用的 direct buffer：虽然 GC 最终会回收，但显式调用
cleaner.clean()（需反射）或复用缓冲区池更可控 - 大文件传输慎用全量内存映射（MappedByteBuffer）：映射 10GB 文件不等于占用 10GB 物理内存，但虚拟地址空间和懒加载策略可能导致不可预期的 page fault 行为
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
