Java数组扩容机制解析：内存动态调整原理

Java中所谓的“数组扩容”本质上是一场精巧的内存腾挪：当ArrayList的元素数量触及底层原生数组的物理边界时，系统会创建一个更大的新数组，通过System.arraycopy高效迁移数据，并更新引用——因为Java原生数组长度不可变，扩容从来不是拉伸，而是替换。首次添加触发10容量的懒分配，后续按1.5倍增长但严格兜底满足最小需求，配合延迟初始化实现内存零浪费；而真正决定扩容时机的，是size与elementData.length之间那条不容妥协的等号判断。理解这一点，才能避开手动实现时忘记更新容量、误用for循环复制、或按数组长度而非实际元素数遍历等致命陷阱。

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 的判断线。

以上就是本文的全部内容了，是否有顺利帮助你解决问题？若是能给你带来学习上的帮助，请大家多多支持golang学习网！更多关于文章的相关知识，也可关注golang学习网公众号。