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() 可能生成超大数组）。
