ArrayList扩容机制详解与底层原理

ArrayList的扩容机制看似简单，实则暗藏诸多性能陷阱：它并非“快满才扩”，而是“刚满即扩”，首次扩容直接跃升至10，后续按近似1.5倍（oldCapacity + oldCapacity>>1）增长，但addAll等批量操作会跳过倍增逻辑、直击最小所需容量；真正拖慢性能的不是计算本身，而是每次扩容背后 unavoidable 的数组复制开销——逐字节拷贝让O(n)成本累积显著；因此，合理预估初始容量（如明确数量时直接指定、上限可控时取上界、动态数据前调用ensureCapacity）或优先使用addAll替代循环add，才是避免频繁扩容、兼顾内存效率与写入性能的关键所在。

add() 时怎么触发扩容？

每次调用 add()，ArrayList 都会先检查当前数组是否还能塞下新元素：如果 size == elementData.length，就立刻扩容。不是“快满了”才扩，而是“刚好满”就扩——这点很多人误以为有缓冲余量，其实没有。

• 无参构造（new ArrayList()）首次 add() 时，elementData 是空数组，此时直接初始化为长度 10
• 指定容量构造（new ArrayList(100)）后，直到第 101 次 add() 才触发第一次扩容
• 扩容判断发生在赋值前，所以 add() 是原子性失败：要么成功插入，要么抛 OutOfMemoryError（极少），不会出现“插了一半卡住”的状态

扩容计算规则是啥？1.5 倍可靠吗？

绝大多数情况下，新容量 = 旧容量 + 旧容量右移 1 位，也就是 oldCapacity + (oldCapacity >> 1)，约等于 1.5 倍。但这个公式只在“常规增长”时生效；当一次性要加大量元素（比如 addAll()），它会跳过 1.5 倍，直接按需扩到最小够用的容量。

• 从 10 → 15 → 22 → 33 → 49 → 73 → 109 …… 不是严格等比，因为右移是整数运算，小容量时误差明显
• addAll() 传入 200 个元素，而当前 size=50、容量=64，它不会扩成 96，而是直接扩到 250（50+200），避免二次扩容
• 如果旧容量是 0（极少见），扩容逻辑会直接设为 1，而不是算 0>>1=0 导致死循环

为什么频繁 add() 性能差？关键瓶颈在哪？

扩容真正的代价不在“乘以 1.5”，而在 Arrays.copyOf() —— 它要分配新内存、逐字节复制老数组内容，是典型的 O(n) 操作。一次扩容可能花几微秒，但 10 次就是几十微秒，对高频写入场景很敏感。

• 1000 个元素从空集合开始逐个 add()，大概触发 10 次扩容（10→15→22→…→1000），拷贝总数据量超 3000 元素次
• 同量数据改用 new ArrayList(1000) 初始化，零扩容，拷贝总量为 0
• 别迷信“JVM 优化”——数组拷贝无法被 JIT 完全消除，尤其是大对象数组，GC 压力也会同步上升

怎么预估初始容量才不翻车？

预估不是猜，而是看数据来源是否可控。如果容量估算偏差过大（比如预设 1000，实际只存 3 个），虽不报错，但浪费内存；若预设太小（如 10），又退回频繁扩容的老路。

• 已知确切数量：直接用 new ArrayList(n)，最稳
• 知道范围上限：取上限值，宁大勿小，比如“最多 500 条日志”，就设 500
• 来源不可控（如用户输入、网络响应）：用 ensureCapacity(int minCapacity) 在批量操作前兜底，例如解析 JSON 数组前先 list.ensureCapacity(jsonArray.size())
• 别用 size() 或 capacity() 反推——capacity() 不是 public 方法，得反射或靠 elementData.length，不推荐

真正容易被忽略的，是批量添加场景下 addAll() 的隐式扩容优化——它比手动循环 add() 高效得多，但前提是传入的集合本身不带“假大小”（比如 Arrays.asList().subList() 返回的代理列表，toArray() 可能生成超大数组）。

文中关于的知识介绍，希望对你的学习有所帮助！若是受益匪浅，那就动动鼠标收藏这篇《ArrayList扩容机制详解与底层原理》文章吧，也可关注golang学习网公众号了解相关技术文章。