BufferUnderflowException 是 Java NIO 中因 position ≥ limit 仍尝试读取导致的状态误用型异常；常见于未 flip()、重复读取、误用 slice()/duplicate() 或未校验 remaining() 就读取。
BufferUnderflowException 是 Java NIO 中典型的**状态误用型异常**，不是数据内容问题，而是缓冲区内部指针越界导致的——当你调用 get()、getInt() 等读取方法时，当前 position 已经 ≥ limit，缓冲区“没数据可读”了，JVM 就直接抛出该异常。
根本原因：读取操作超出了有效数据边界
ByteBuffer 的读写依赖三个关键状态：position（当前读/写位置）、limit（可操作上限）、capacity（总容量）。下溢发生，本质是 position >= limit 时仍尝试读取。常见触发点包括：
- 未调用
flip()就直接读：比如从SocketChannel.read(buffer)接收数据后，position是实际读到的字节数，但limit还是初始容量值；不flip()，limit不会自动收缩，后续get()会误读未写入区域 - 重复读取未重置：一次
getInt()后position增加 4，再读一次又增 4……直到超过limit，第 N+1 次就崩 - 用
slice()或duplicate()得到新缓冲区后，忽略其独立的position和limit：例如原缓冲区position=8, limit=10，slice()出来的子缓冲区position=0, limit=2，但若你误以为它能读 10 字节，就会在第 3 次get()时触发异常 - 读取固定长度字节数组时未校验剩余空间：如
byte[] tmp = new byte[3]; buffer.get(tmp);，但buffer.remaining() < 3，必然下溢
典型错误代码片段还原
下面这段解析协议头的代码极易出错：
buffer.get(header); // 读4字节header byte cmd = buffer.get(); // 读1字节cmd short len = buffer.getShort(); // 读2字节length byte[] ts = new byte[6]; buffer.get(ts); // 读6字节时间戳
只要任意一步前 buffer.remaining() 不足，后续调用立即抛 BufferUnderflowException。日志里看到堆栈指向某行 getXXX()，问题就一定出在那一行的前置状态上。
deep-java-review
下载
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
立即学习“Java免费学习笔记（深入）”；
为什么不能靠 try-catch 来兜底
这个异常属于 RuntimeException 子类，但它反映的是**逻辑缺陷**，不是偶发故障。捕获它相当于把“数组越界”当正常流程处理——既掩盖真实问题，又拖慢性能。Java 官方文档和 NIO 最佳实践都强调：应通过显式状态检查预防，而非异常恢复。
安全读取的核心动作
真正可靠的写法不是加 try-catch，而是让每一步读取都有依据：
- 每次调用
get()前，先用buffer.hasRemaining()判断是否还有数据可读 - 读固定长度数组时，用
if (buffer.remaining() >= length)校验，而不是硬写get(array) - 网络接收后，立刻
buffer.flip()，再进入解析逻辑 - 调试时加一行打印：
System.out.printf("pos=%d, lim=%d, rem=%d%n", buf.position(), buf.limit(), buf.remaining());，状态一目了然
