bytebuffer 不支持动态扩容，因 capacity 是 final 字段；手动扩容需 flip→compact→allocate新buffer→copy→替换引用；推荐预分配多档缓冲区、使用缓冲池（如 netty）、改用 bytebuf 或协议层分段读取。
ByteBuffer 本身不支持动态扩容，容量在创建时就固定了，无法像 ArrayList 那样自动增长。所谓“动态调整容量”，实际是应用层手动完成的：检测空间不足 → 分配新 buffer → 复制旧数据 → 替换引用。关键不在 ByteBuffer 自身，而在你怎么用它。
为什么不能直接扩容
ByteBuffer 的 capacity 是 final 字段，创建后不可修改。调用 put() 超出 limit 会抛 BufferOverflowException；即使调用 compact() 或 flip()，也只是移动 position/limit，不改变 capacity。这是设计使然——NIO 强调零拷贝和确定性内存行为，避免隐式分配带来的性能抖动和 GC 压力。
手动扩容的典型步骤
当发现当前 buffer 不足以容纳待写入数据（例如解析出消息体长度为 12KB，但当前 buffer 只有 2KB）时，按以下顺序操作：
- 调用 buffer.flip() 确保已读数据处于可访问状态
- 用 buffer.remaining() 获取当前未读字节数，判断是否够解析 header（如 4 字节 length 字段）
- 若不够，先 buffer.compact() 压缩已读部分，腾出空间继续 read；若仍不足，新建 buffer
- 调用 ByteBuffer.allocateDirect(newCapacity) 或从缓冲池取一个合适大小的新 buffer
- 将原 buffer 中未读数据 put() 到新 buffer，注意要先 flip 再 copy
- 更新引用，后续读写基于新 buffer 进行
更实用的替代方案
频繁手动扩容易出错且低效。生产环境推荐以下方式：
- 预分配多档缓冲区：准备 1KB / 4KB / 16KB 几种常见规格，按协议预期长度选取，避免盲目翻倍
-
使用缓冲区池：如 Netty 的
PooledByteBufAllocator，支持自动扩容（底层仍是 allocate + copy），并复用内存 -
改用 ByteBuf：Netty 的 ByteBuf 封装了自动扩容逻辑（如 writeBytes() 超限时触发
ensureWritable0），读写指针分离，无需 flip/clear - 协议层预留空间：在 header 后留出 padding 字节，或采用分段读取（先读 header，再按 bodyLength 分配 buffer）
堆内 vs 堆外 buffer 的选择
扩容操作本身不区分 heap/direct，但影响显著：
- 堆内 buffer（
allocate()）：分配快、GC 管理，适合短生命周期、小数据；但 I/O 时可能触发额外拷贝（JVM 需转成 direct 才能进内核） - 堆外 buffer（
allocateDirect()）：I/O 零拷贝，适合长期复用的网络收发缓冲；但分配销毁开销大，需控制-XX:MaxDirectMemorySize防 OOM - 高频场景下，优先复用 direct buffer 池，而非每次 allocateDirect + copy
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
