Arrays.copyOf 是控制堆内存分配节奏的关键操作，通过按需扩容、阶梯式增长和截断替代重建来减少无效分配、避免引用残留，配合 GC 高效回收。
Arrays.copyOf 不是内存管理的“开关”，而是控制堆内存分配节奏的关键操作。它不直接释放内存，但能减少无效分配、避免引用残留、配合 GC 更高效回收——真正优化内存，靠的是用对时机和长度。
按需扩容，杜绝冗余空间浪费
很多系统在预估容量时过度保守，比如固定分配 1024 字节缓冲区，实际每次只用 64 字节。长期下来，大量未用空间堆积在堆中，拖慢 GC 扫描效率。
- 改用动态策略：接收数据前先估算长度（如 HTTP Content-Length、协议头声明），再调用 Arrays.copyOf(src, estimatedLen)
- 若无法预估，采用“阶梯式增长”：首次不足时扩为 2 倍，第二次不足再扩为 1.5 倍，而非无脑翻倍
- 扩容后注意清理旧引用：src = Arrays.copyOf(src, newLen); —— 原数组若无其他强引用，可被快速回收
截断替代重建，降低 GC 频率
处理日志、消息体、分页数据时，常需“取前 N 条”。若用 new int[N] + 循环复制，等于额外创建一个对象；而 Arrays.copyOf(arr, N) 在 N
- 适用于缓存快照、DTO 截取、协议字段提取等场景
- 特别适合 short-lived 临时副本：比如 Web 请求中构造响应体，用完即弃，截断比全量拷贝更轻量
- 注意：截断后数组长度变小，但底层元素仍保留在原位置 —— 不影响 GC，因整个原数组若已无引用，整块内存仍可回收
统一类型默认值填充，避免脏数据干扰 GC
Arrays.copyOf 扩容时自动填充默认值（int→0、Object→null），这看似是便利特性，实则影响内存行为：
立即学习“Java免费学习笔记（深入）”；
- 填 0 或 null 可确保新位置不持有所谓“幻影引用”，防止本该回收的对象因残留引用而滞留
- 避免手动循环赋 null 的错误：有人写 for (int i = oldLen; i
- 对 byte[] 缓冲区尤其重要：未初始化的字节可能包含旧数据残影，影响安全审计或序列化一致性
配合对象池，让 copyOf 成为“可控分配”入口
在高频收发场景（如 Netty 的 ByteBuf、自定义消息队列），完全禁用 new 数组不现实。此时可将 Arrays.copyOf 作为对象池的“适配层”：
- 池中预分配若干固定尺寸 byte[]（如 1KB、4KB、16KB）
- 需要拷贝时，先选最接近且 ≥ 所需长度的池数组，再用 System.arraycopy 搬入数据；仅当池中无合适尺寸时，才走 Arrays.copyOf 新建
- 这样既保留 copyOf 的简洁性，又把大部分分配转为复用，GC 压力显著下降
不复杂但容易忽略：内存优化不在代码多炫，而在每一次 new 和 copy 的决策里。Arrays.copyOf 本身轻量，但它背后的选择逻辑，决定了堆里是干净的碎片，还是缠绕的引用网。
