扩容必须分“分配新数组”和“拷贝数据”两步，因Java数组长度固定；System.arraycopy()仅搬运数据，不创建数组，其高效源于绕过JVM抽象、调用硬件级内存指令、连续地址访问及免写屏障。
直接用 system.arraycopy() 本身不能“实现扩容”，它只负责拷贝——扩容的关键动作是“先分配新数组，再拷贝”。但正是这个组合，构成了 java 中最轻量、最贴近硬件的扩容路径，对 cpu 内存带宽的利用也最为高效。
为什么扩容必须分两步：分配 + 拷贝
数组在 Java 中是固定长度对象，无法动态伸缩。System.arraycopy() 不创建新数组，也不修改原数组长度。它只把已有数据从一个内存块搬移到另一个内存块。所以标准扩容流程是：
- 计算新容量（例如当前长度 × 1.5）
-
new int[newCapacity]或new Object[newCapacity]分配连续内存 - 调用
System.arraycopy(oldArr, 0, newArr, 0, oldLength)搬运有效元素
这三步中，第二步触发堆内存分配（可能涉及 GC），第三步才是真正的数据搬运——也是唯一能压榨内存带宽的环节。
System.arraycopy 如何高效利用 CPU 内存带宽
它绕过 Java 层一切抽象，直连硬件级内存操作：
- 不走字节码循环：避免每次
a[i]都检查边界、空指针、类型，省去数百次冗余判断 - 底层映射为
memmove或向量化指令：HotSpot 在编译时根据数组类型和长度，自动选择最优 stub——小数组用紧凑汇编，大数组启用 SSE/AVX 批量加载/存储，一次指令处理 16–64 字节 - 连续地址访问：源与目标均为连续内存块，CPU 预取器（prefetcher）可准确预测后续地址，大幅减少 cache miss 和内存等待周期
- 无写屏障干扰（对基本类型）：
int[]、byte[]等拷贝不触发 GC 写屏障，避免卡表（Card Table）更新开销，释放 DDR 总线带宽给纯数据搬运
对比手动 for 循环：带宽损耗在哪
一段典型的手动拷贝：
for (int i = 0; i < len; i++) {
newArr[i] = oldArr[i];
}
每轮迭代实际发生：
- CPU 读
oldArr基址 +i×4→ 触发 TLB 查找 + cache line 加载 - 读
newArr基址 +i×4→ 同样开销，且写操作还可能引发 write-allocate - 每次都要重算索引、比较
i < len、递增i→ 占用 ALU 和寄存器 - JIT 很难将这种跨数组、含分支的循环向量化
而 arraycopy 把整段搬运抽象为单条语义指令，JVM 可将其编译为类似 rep movsd 的 CPU 原语——一条指令隐含多次内存事务，由微码或硬件加速器完成，带宽利用率接近物理上限。
实际扩容中的关键细节
真正影响带宽发挥的不是方法本身，而是你怎么用：
- 确保目标数组已分配且足够大：若
newArr.length < oldLength，直接抛IndexOutOfBoundsException，根本没机会启动搬运 - 避免跨代拷贝（如老年代对象数组 → 新生代数组）：会强制触发写屏障，增加卡表更新压力，间接拖慢带宽吞吐
- 对象数组只复制引用：
String[]扩容时，搬运的是 8 字节指针，不是字符串内容本身——带宽压力极小；但若需深拷贝，必须另做处理 - 长度尽量对齐：某些 JVM 实现对 8/16 字节对齐的拷贝有额外优化，虽然不强制要求，但
Arrays.copyOf内部扩容常按 1.5 倍向上取整到最近 2 的幂，有一定带宽友好倾向
不复杂但容易忽略
