扩容必须分“分配新数组”和“拷贝数据”两步，因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 
<p>每轮迭代实际发生：</p>

• CPU 读 oldArr 基址 + i×4 → 触发 TLB 查找 + cache line 加载
• 读 newArr 基址 + i×4 → 同样开销，且写操作还可能引发 write-allocate
• 每次都要重算索引、比较 i 、递增 <code>i → 占用 ALU 和寄存器
• JIT 很难将这种跨数组、含分支的循环向量化

而 arraycopy 把整段搬运抽象为单条语义指令，JVM 可将其编译为类似 rep movsd 的 CPU 原语——一条指令隐含多次内存事务，由微码或硬件加速器完成，带宽利用率接近物理上限。

实际扩容中的关键细节

真正影响带宽发挥的不是方法本身，而是你怎么用：

• 确保目标数组已分配且足够大：若 newArr.length ，直接抛 <code>IndexOutOfBoundsException，根本没机会启动搬运
• 避免跨代拷贝（如老年代对象数组 → 新生代数组）：会强制触发写屏障，增加卡表更新压力，间接拖慢带宽吞吐
• 对象数组只复制引用：String[] 扩容时，搬运的是 8 字节指针，不是字符串内容本身——带宽压力极小；但若需深拷贝，必须另做处理
• 长度尽量对齐：某些 JVM 实现对 8/16 字节对齐的拷贝有额外优化，虽然不强制要求，但 Arrays.copyOf 内部扩容常按 1.5 倍向上取整到最近 2 的幂，有一定带宽友好倾向

不复杂但容易忽略