ArrayList扩容机制及容量管理解析

本文深入剖析了ArrayList的扩容机制与容量管理策略，揭示其在add()时“刚好满即扩容”的严格触发逻辑、首次扩容至10及后续约1.5倍（实际为oldCapacity + oldCapacity>>1）增长的计算本质，并指出addAll()会智能跳过倍增、直接按需扩容以避免二次开销；文章直击性能瓶颈——Arrays.copyOf()引发的O(n)内存拷贝代价，强调预设初始容量对高频写入场景的关键影响，同时提供基于数据可控性的精准容量估算方法和ensureCapacity()兜底实践，辅以易被忽视的批量添加优化细节，助你彻底告别低效扩容陷阱。

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学习网公众号了解相关技术文章。