ArrayList扩容机制解析与底层原理揭秘

文章不知道大家是否熟悉？今天我将给大家介绍《ArrayList扩容机制详解与底层原理说明》，这篇文章主要会讲到等等知识点，如果你在看完本篇文章后，有更好的建议或者发现哪里有问题，希望大家都能积极评论指出，谢谢！希望我们能一起加油进步！

ArrayList在add()时立即扩容：size等于数组长度时触发，无缓冲余量；首次add空数组扩容至10，后续按1.5倍（oldCapacity + oldCapacity>>1）增长，addAll则直接扩至所需最小容量。

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学习网公众号吧！