ArrayList扩容机制及底层原理解析

ArrayList的扩容机制并非简单的“满即扩”，而是严格在size等于数组长度时立即触发，首次扩容固定为10，后续常规增长采用oldCapacity + oldCapacity>>1（约1.5倍）但受整数运算影响并非精确等比，而addAll等批量操作则智能跳过倍增逻辑、直接扩至所需最小容量；真正影响性能的不是计算本身，而是Arrays.copyOf()引发的O(n)内存分配与数据拷贝，频繁逐个add可能造成十余次无效复制，而合理预估初始容量或使用ensureCapacity提前兜底，配合批量添加替代循环add，可显著规避扩容开销与GC压力——理解这些底层细节，才能写出既高效又健壮的集合操作代码。

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学习网公众号，给大家分享更多文章知识！