Java数组扩容机制全解析

Java中所谓的“数组扩容”本质上是一场巧妙的内存迁移：当ArrayList添加元素导致逻辑大小（size）触及物理容量（elementData.length）时，系统并非修改原数组长度（因Java原生数组不可变），而是创建更大新数组，通过高度优化的System.arraycopy高效搬运数据，并更新引用——首次扩容默认分配10个元素空间，后续按1.5倍增长但严格保障不低于实际需求，配合延迟初始化（无参构造不立即分配内存）与精准的容量判断逻辑，既节省资源又兼顾性能；理解这一机制的关键，在于认清size与length的本质差异、摒弃“手动维护capacity字段”的误区，并始终以array.length为真实容量基准。

Java 中的“数组扩容”不是真的在原地拉长数组，而是创建一个更大的新数组，把旧数据搬过去，再让引用指向它——因为 int[]、Object[] 这类原生数组长度一旦确定就不可变。

为什么 ArrayList.add() 会触发扩容？

关键判断就这一行：if (size == elementData.length)。它不看“还剩几个空位”，只看“当前逻辑大小是否顶到物理边界”。只要下一个元素要放进去时发现没空间了，立刻调用 grow()。

• 第一次 add()：即使 elementData 是空数组（长度为 0），也会进 grow(size + 1)，然后兜底返回 new Object[10]
• 后续添加：每次检查都基于当前 size 和当前 elementData.length，不是和初始容量比
• 注意：size 是元素个数，elementData.length 是数组实际长度，二者长期不等——这是设计，不是 bug

扩容计算不是简单 ×1.5，而是两步保底

grow() 里真正算新容量的逻辑是：oldCapacity + (oldCapacity >> 1)（即 1.5 倍），但紧接着会和「这次操作至少需要多少」比大小，取大者。

• 比如从容量 1 扩容：1 + (1>>1) = 1 + 0 = 1 → 仍不够存第 2 个元素 → 直接用 minCapacity = 2
• 批量 addAll() 时，minCapacity 是 size + 集合大小，所以可能跳过 1.5 倍，直接扩到 500
• 极端小容量（如 new ArrayList(1)）不会反复微扩，靠这个兜底一步到位

手动模拟扩容时最容易漏掉的关键点

自己写动态数组类时，90% 的失效扩容都源于没同步更新“容量感知字段”。常见错误代码里：resize() 创建了新数组，但没更新 capacity 变量，或误用 size 当容量来算新长度。

• 正确做法：删掉冗余的 capacity 字段，直接用 array.length 判断是否满、计算新大小
• 复制必须用 System.arraycopy()，别手写 for 循环——JVM 对前者有深度优化
• 打印/遍历时，永远按 pointer（已存元素数）而非 array.length 遍历，否则输出一堆 0

最常被忽略的其实是“延迟初始化”这个细节：无参构造的 ArrayList 底层一开始连 10 都不分配，elementData 指向的是一个共享的空数组对象；直到第一次 add() 才真正分配 10。这意味着，如果你只创建不添加，它几乎不占堆内存——但一旦开始加，就得准备好面对那条 size == elementData.length 的判断线。

理论要掌握，实操不能落！以上关于《Java数组扩容机制全解析》的详细介绍，大家都掌握了吧！如果想要继续提升自己的能力，那么就来关注golang学习网公众号吧！