readonlybufferexception 是 java.nio.buffer 子类主动抛出的，当在只读缓冲区上调用 put()、compact() 等修改方法时触发；判断只读性唯一可靠方式是 isreadonly()；无法解除只读，只能拷贝可写副本。
ReadOnlyBufferException 是谁抛的？
这个异常不是 JVM 随便扔的，而是 java.nio.Buffer 子类（比如 ByteBuffer、CharBuffer）在检测到「写操作」发生在只读缓冲区上时主动抛出的。它不关心你是不是有意为之，只要调用了 put()、compact()、flip()（部分重载）、rewind()（某些实现）等会修改位置或内容的方法，就会触发。
常见错误现象：
- 从
asReadOnlyBuffer()得到缓冲区后，误当成普通缓冲区调用put() - 用
wrap(byte[])包装一个数组，但后续又调用asReadOnlyBuffer()，再传给某个期望可写的 API - 第三方库返回了只读视图（如 Netty 的
Unpooled.unmodifiableBuffer()），你没注意文档直接改
怎么判断一个 Buffer 是只读的？
别猜，直接问它：isReadOnly() 是唯一可靠方式。不要依赖来源（比如“我 wrap 的数组肯定可写”）——因为中间可能被转成只读视图。
使用场景中容易忽略的点：
立即学习“Java免费学习笔记（深入）”；
-
asReadOnlyBuffer()返回的新缓冲区共享底层数据，但标记为只读；原缓冲区状态不受影响 -
slice()和duplicate()继承原缓冲区的只读性，不是“默认可写” - 通过
allocateDirect()或allocate()创建的缓冲区默认可写，但一旦调用过asReadOnlyBuffer()，就不可逆
想改只读 Buffer 的内容，该怎么做？
不能绕过限制硬改，只能换思路：复制一份可写的副本。没有“解除只读”的 API，这是设计使然。
实操建议：
- 如果原始数据是数组（比如你用
wrap(arr)创建的），直接操作arr，别碰缓冲区 - 如果是堆外缓冲区或来源不明，用
ByteBuffer.allocate(buffer.remaining()).put(buffer).flip()拷贝（注意容量和 position/limit） - 用
buffer.hasArray()+buffer.array()提取底层数组（仅限堆缓冲区且未只读化前；只读缓冲区调用array()会抛ReadOnlyBufferException） - 避免无谓拷贝：先确认是否真需要修改——很多场景其实只需读，强行写反而引入 bug
为什么不让只读 Buffer 变可写？
这是 NIO 的安全契约：只读视图用于向不可信代码暴露数据，防止意外篡改。JVM 不提供后门，也不允许反射破坏（readonly 字段是 final 且被 native 层保护）。
性能与兼容性影响：
- 所有只读检查都在方法入口做，开销极小（一次布尔判断）
- Java 9+ 的
VarHandle或 Unsafe 也不能绕过，底层 C 实现直接拒绝写入 - 不同 JDK 版本行为一致，不存在兼容性差异——这点很稳
最容易被忽略的复杂点：只读性会沿继承链传递，比如 duplicate().asReadOnlyBuffer().slice() 还是只读的，而且你很难从外部反推它的“祖先”是否可写。所以别试图恢复，老老实实拷贝。
