ByteBuffer 不支持自动扩容，需手动处理或改用 ByteBuf；手动扩容需判断容量、新建缓冲区并复制数据；ByteBuf 支持动态扩容与内存池；应结合协议预分配、复用缓冲池，并避免误用 clear()。
Java NIO 的 ByteBuffer 本身不支持自动扩容，容量固定，一旦分配就不能改变。当写入数据超出其 capacity，必须由应用层主动处理——要么手动创建更大缓冲区并复制数据，要么换用更合适的缓冲机制（如 Netty 的 ByteBuf）。关键不在“能不能”，而在于“什么时候扩、怎么扩更合理”。
手动扩容 ByteBuffer 的标准做法
这是最直接的应对方式，适用于必须使用原生 NIO、又无法引入第三方库的场景：
- 调用
buffer.capacity()获取当前容量，用buffer.position()和buffer.limit()判断已写入字节数（即buffer.position()） - 若
position == limit且还需写入，说明已满；若预估后续还需写入 N 字节，而limit - position ，就该扩容 - 新建更大缓冲区（常见策略是翻倍或按需设为
Math.max(2 * oldCap, neededSize)） - 将原 buffer 切换到读模式（
flip()），再put()到新 buffer；最后对新 buffer 调用compact()或重置指针以便继续写入
用 ByteBuf 替代 ByteBuffer（推荐）
Netty 的 ByteBuf 天然支持动态扩容，内部封装了安全的扩容逻辑，避免越界异常和手动拷贝：
Java 接口排错助手
下载
在调试 Java 后端 API 故障时使用此技能，尤其适用于以下任务：分析日志、跨 Controller、Service 和 Mapper 层追踪请求、定位异常根因、检查 SQL 执行或参数流转，以及生成简洁的诊断结论与修复方案。
- 调用
writeBytes(byte[])或writeInt()等方法时，若剩余空间不足，会自动分配新 buffer 并迁移数据 - 默认使用
PooledByteBufAllocator，支持内存池管理，减少 GC 压力 - 读写指针分离（
readerIndex/writerIndex），无需反复flip()/clear()，状态更清晰
基于 Selector 的智能预分配策略
在 NIO 服务端中，不应等真正写爆才扩容，而应结合协议特征提前决策：
- 采用“TLV”格式（如 4 字节长度前缀 + 变长 body）时，先用小 buffer（如 8 字节）读取 header，解析出 body 长度后，再分配精确大小的 buffer
- 复用缓冲区池：用
ThreadLocal或轻量对象池维护几档常用容量（如 1KB / 8KB / 64KB），避免频繁分配释放 - 参考 Netty 的
AdaptiveRecvByteBufAllocator思路：根据最近几次实际读取字节数动态调整下一次分配大小，在 64B～64KB 区间内自适应伸缩
避坑提醒：别在错误时机调 clear()
很多问题不是因为没扩容，而是误用了状态操作：
-
clear()不是“清空数据”，只是重置指针（position=0, limit=capacity），之前未读的数据还在内存里 - 紧接着
channel.read(buffer)会从头覆盖，导致半包数据丢失 - 正确做法是：已读部分处理完后，残留未读数据应调
compact()，把未读内容移到开头，再继续读
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
