ArrayList扩容系数1.5的原理与优势

ArrayList采用1.5倍扩容系数（通过位运算`oldCapacity + (oldCapacity >> 1)`高效实现）并非随意选择，而是Java团队在长期实践中权衡内存连续性、摊还时间复杂度、JVM底层优化与堆碎片适应性后得出的“足够好”平衡点：它既避免了小倍数导致的频繁拷贝（如1.2倍使总复制量达5n），又规避了2倍扩容在碎片化内存中易失败的风险，同时以零浮点开销、无溢出隐患的整数运算赢得CPU指令级优化；从10→15→22→33的渐进式增长虽不追求2的幂对齐，却显著降低OOM概率，尤其在资源受限的移动端或长周期服务中——理解这一设计，不仅能写出更高效的集合操作（如预设容量替代循环add），更能窥见JDK如何将算法、硬件特性和运行时环境深度协同。

扩容不是乘法，是位运算加法

ArrayList 的 1.5 倍扩容根本没用 oldCapacity * 1.5，而是用 oldCapacity + (oldCapacity >> 1)。右移一位等价于整数除以 2，所以这本质是向下取整的 1.5 倍——比如容量为 7 时，7 >> 1 是 3，新容量就是 10，不是 10.5。

这么做的直接好处是：避开浮点运算、避免除法指令开销、无溢出风险（对非负数），JVM 能把它优化成一条或两条 CPU 指令。如果你在 hotspot 日志里看编译热点，grow() 里的这行计算几乎不占周期。

• 别在代码里手动模拟 * 1.5，结果可能因类型转换或 rounding 行为不一致
• 奇数容量扩容“少扩一点”是正常现象，不是 bug；连续扩容序列如 10 → 15 → 22 → 33 → 49 就是这么来的
• 当 oldCapacity 接近 Integer.MAX_VALUE - 8 时，oldCapacity >> 1 可能导致 newCapacity 溢出为负，此时会 fallback 到 hugeCapacity()

1.5 倍是为连续内存“留缝”，不是为凑整数

数组必须分配连续内存块，而 JVM 堆的空闲空间是碎片化的。2 倍扩容（如 100 → 200）容易卡在“有 150 字节空闲但凑不出 200 字节连续块”的窘境；1.5 倍（100 → 150）更大概率能从现有碎片中拼出所需空间。

这不是玄学——在移动端或容器化部署中，堆初始大小受限，频繁触发 GC 后内存趋于离散，1.5 倍的渐进式增长明显降低 OutOfMemoryError: Java heap space 的发生概率，尤其在长期运行的日志采集线程里。

• 不要误以为“1.5 倍是为了让容量是 2 的幂”，它恰恰不是：10、15、22、33 全都不是 2 的幂，这对 ArrayList 完全无关紧要
• HashMap 要求 2 的幂是为了 & (n-1) 替代 % n，ArrayList 随机访问靠的是 base + index * scale，不需要哈希对齐
• 真正影响内存布局的是分配时机：每次扩容都 new 一块连续内存，旧数组等待 GC；若对象本身较大（如 byte[]），复制压力会集中在老年代

扩容阈值藏在 add() 的第一行检查里

扩容不是等数组填满才发生，而是在每次 add(E) 执行前，先调用 ensureCapacityInternal(size + 1) 判断是否够用。也就是说，第 11 个元素插入前，就已决定要把容量从 10 扩到 15。

这个设计暴露了一个关键事实：ArrayList 的容量永远 ≥ size，但 size 永远不驱动扩容——只有“即将写入”这个动作才触发。这也是为什么 addAll() 传入大集合时，会一步到位扩到至少 size + c.size()，跳过中间所有 1.5 倍小步扩容。

• 循环里反复 add() 却不预设容量，等于主动触发 10→15→22→33→49… 多次 Arrays.copyOf()，每次都是 O(n) 拷贝
• size() 返回当前元素数，但你看不到 capacity；想观察真实扩容行为，得用反射读 elementData.length 或借助 JFR 事件
• 构造时指定 new ArrayList(1000)，比默认构造后 add 1000 次快 3–5 倍（实测 JDK 17–21），主因就是省掉约 10 次拷贝

1.5 倍的平衡点，卡在摊还成本与内存浪费之间

从数学上看，按 1.5 倍扩容，插入 n 个元素的总复制次数是几何级数和：≈ 2n。均摊下来每次插入的复制成本是常数级 O(1)；换成 1.2 倍，总复制次数飙升到 ≈ 5n，CPU 时间明显上涨；换成 2 倍，总复制降到 ≈ n，但内存闲置率翻倍——100 个元素占着 200 的数组，GC 扫描范围扩大，元空间压力也增加。

这个 1.5 是经验值，不是推导值。它被 JDK 从 1.2 版本沿用至今，不是因为最优，而是因为足够好且生态已适配：subList、iterator 的 fail-fast 逻辑、序列化格式，全都隐含了这一增长节奏。

真正容易被忽略的是边界场景：当单次 addAll() 超过 128MB 的引用数组时，即使你预估了容量，JVM 可能因 TLAB 分配失败而降级到慢速分配路径，这时扩容本身的开销反而不重要了，内存分配器的行为成了瓶颈。

今天带大家了解了的相关知识，希望对你有所帮助；关于文章的技术知识我们会一点点深入介绍，欢迎大家关注golang学习网公众号，一起学习编程~