arraylist.add()触发扩容是因为size等于elementdata.length时调用grow()，首次add分配10容量，后续按1.5倍且不低于最小需求扩容，依赖延迟初始化与system.arraycopy优化。
Java 中的“数组扩容”不是真的在原地拉长数组，而是创建一个更大的新数组，把旧数据搬过去，再让引用指向它——因为 int[]、Object[] 这类原生数组长度一旦确定就不可变。
为什么 ArrayList.add() 会触发扩容？
关键判断就这一行：if (size == elementData.length)。它不看“还剩几个空位”，只看“当前逻辑大小是否顶到物理边界”。只要下一个元素要放进去时发现没空间了，立刻调用 grow()。
- 第一次
add()：即使elementData是空数组（长度为 0），也会进grow(size + 1)，然后兜底返回new Object[10] - 后续添加：每次检查都基于当前
size和当前elementData.length，不是和初始容量比 - 注意：
size是元素个数，elementData.length是数组实际长度，二者长期不等——这是设计，不是 bug
扩容计算不是简单 ×1.5，而是两步保底
grow() 里真正算新容量的逻辑是：oldCapacity + (oldCapacity >> 1)（即 1.5 倍），但紧接着会和「这次操作至少需要多少」比大小，取大者。
- 比如从容量 1 扩容：1 + (1>>1) = 1 + 0 = 1 → 仍不够存第 2 个元素 → 直接用
minCapacity = 2 - 批量
addAll()时，minCapacity是size + 集合大小，所以可能跳过 1.5 倍，直接扩到 500 - 极端小容量（如
new ArrayList(1)）不会反复微扩，靠这个兜底一步到位
手动模拟扩容时最容易漏掉的关键点
自己写动态数组类时，90% 的失效扩容都源于没同步更新“容量感知字段”。常见错误代码里：resize() 创建了新数组，但没更新 capacity 变量，或误用 size 当容量来算新长度。
立即学习“Java免费学习笔记（深入）”；
- 正确做法：删掉冗余的
capacity字段，直接用array.length判断是否满、计算新大小 - 复制必须用
System.arraycopy()，别手写 for 循环——JVM 对前者有深度优化 - 打印/遍历时，永远按
pointer（已存元素数）而非array.length遍历，否则输出一堆 0
最常被忽略的其实是“延迟初始化”这个细节：无参构造的 ArrayList 底层一开始连 10 都不分配，elementData 指向的是一个共享的空数组对象；直到第一次 add() 才真正分配 10。这意味着，如果你只创建不添加，它几乎不占堆内存——但一旦开始加，就得准备好面对那条 size == elementData.length 的判断线。
