ByteBuffer 的 capacity 是创建时固定的总大小，不可变；它本身不防 OOM，但可提前拦截非法大容量申请，需在分配前校验、设阈值、联动 JVM 参数并监控。
ByteBuffer 的 capacity 是创建时就固定的缓冲区总大小，它不随 position 或 limit 变化而改变。合理利用 capacity 本身不能“预防 OOM”，但它能帮你**提前拦截非法的大容量申请**，避免因 unchecked 的 buffer 分配直接触发 OutOfMemoryError: Direct buffer memory 或堆内存耗尽。关键在于：把 capacity 当作一个可校验的边界值，而非默认信任的配置项。
明确 capacity 的作用边界
capacity 表示 ByteBuffer 能容纳的最大字节数，但它的实际影响取决于分配方式：
-
Heap Buffer（
allocate()）：从 JVM 堆中分配，受-Xmx限制；过大的 capacity 会快速吃光堆内存，可能引发Java heap space -
Direct Buffer（
allocateDirect()）：从操作系统本地内存分配，绕过堆，但受限于物理内存和-XX:MaxDirectMemorySize；超限将直接抛Direct buffer memory - capacity 本身不会自动扩容，也不会触发 GC —— 它只是一个静态上限，错误地忽略它，等于放弃第一道防线
在分配前强制校验 capacity 值
不要无条件调用 allocate(1024 * 1024 * 100) 这类硬编码。应在创建前做业务级合理性判断：
- 根据上游数据规模预估：例如网络包最大长度为 64KB，那就设
capacity = 65536，而非预留 1GB - 加入阈值检查逻辑：if (requestedSize > MAX_BUFFER_CAPACITY) { throw new IllegalArgumentException("Buffer size " + requestedSize + " exceeds max allowed " + MAX_BUFFER_CAPACITY); }
- 对动态计算的 capacity（如基于文件大小、消息体长度）加兜底限制，例如不超过 32MB
配合系统参数与监控闭环控制
单靠代码校验不够，需与 JVM 级约束联动：
- 显式设置
-XX:MaxDirectMemorySize=512m，让 direct buffer 超限时抛明确异常，便于捕获和告警 - 使用
BufferPoolMXBean监控 direct buffer 使用量：ManagementFactory.getPlatformMXBeans(BufferPoolMXBean.class)，发现持续高位及时干预 - 日志中记录每次大 buffer 分配的 capacity 和调用上下文，方便回溯是否某处误传了 100MB 当作 100KB
避免常见误用放大风险
这些写法会让 capacity 失去防护意义：
- 用
wrap(byte[])包装超大数组 —— capacity 就是数组 length，但数组本身已占堆内存，没做 length 校验等于绕过检查 - 反复调用
allocateDirect()创建短生命周期 buffer 却不复用 —— 即使单个 capacity 合理，高频分配仍可能触达系统级内存上限 - 把 capacity 当作“建议值”：例如认为 “反正后续会 flip/compact，小点也没事”，结果因协议要求必须一次性 hold 整帧数据，被迫现场扩容失败
