InvalidMarkException 是因 Buffer 的 mark 位置失效（如 clear()/flip()/compact() 后 mark 被置为 -1）却仍调用 reset() 导致的异常；需用 hasMark() 检查或改用 duplicate()、手动 position() 避免。
InvalidMarkException 是什么，为什么会抛这个异常
它不是你代码写错了语法，而是 Buffer 的标记（mark）被“弄丢”了——比如调用了 reset() 但之前没 mark()，或者 clear()/flip() 后 mark 被自动丢弃。NIO 缓冲区的 mark 是个可选位置指针，一旦缓冲区状态重置（如 clear()），mark 就失效，再 reset() 就直接炸。
哪些操作会悄无声息地清空 mark
很多人以为只有自己没调 mark() 才会出问题，其实更常见的是“合法操作”顺手把 mark 给干掉了：
-
clear()：重置 position=0、limit=capacity，mark = -1（即无效） -
flip()：limit = position, position = 0，mark = -1 -
compact()：移动数据后重设 position 和 limit，mark = -1 -
rewind()：只重置 position=0，mark 不变（这是少数能保留 mark 的操作）
怎么安全地用 mark / reset 避免 InvalidMarkException
核心原则：mark 不是持久状态，它只在“你明确知道当前 buffer 没被重置过”的上下文中才可靠。实际编码中建议：
- 用
hasMark()显式检查，而不是无脑reset()——if (buf.hasMark()) buf.reset(); - 避免跨方法传递已 mark 的 buffer，除非你能完全控制调用链中所有 buffer 操作
- 如果需要多次回退，别依赖 mark/reset，改用
duplicate()或记录 position 值手动position(int) - 注意
ByteBuffer.allocateDirect()和堆内 buffer 行为一致，mark 失效逻辑无区别
一个典型踩坑场景：读取不定长消息时误用 mark
比如用 SocketChannel.read(buf) 接收协议头，想先 mark 再 peek，结果中间穿插了 flip() 解析——此时 mark 已死，后续 reset() 必抛 InvalidMarkException：
立即学习“Java免费学习笔记（深入）”；
buf.mark(); // 想回头重读 int n = channel.read(buf); buf.flip(); // ... 解析 header，发现长度不够，想 reset 重读 if (buf.hasMark()) buf.reset(); // ✅ 安全 else buf.position(0); // ❌ 别假设 mark 还在
真正麻烦的不是异常本身，是 mark 失效没有 warning，它就静默归零，等你 reset() 时才报错——所以关键不是“怎么 catch”，而是“怎么提前不给它失效的机会”。
