ArrayList扩容在add()时触发：先判断size==elementData.length，满则扩容；首次扩容至10，后续按1.5倍增长，不足则取所需最小容量，超限进hugeCapacity()；1.5倍是空间与时间的工程折中；预设容量可避免频繁扩容。
add() 时怎么触发 ArrayList 扩容？
扩容不是“定时发生”，而是每次调用 add() 时，先检查是否还有空位：如果 size == elementData.length，立刻扩容。注意，size 是当前元素个数，elementData.length 是底层数组长度——两者相等就“满了”，必须搬新家。
- 首次
add()：无参构造的ArrayList底层是空数组（DEFAULTCAPACITY_EMPTY_ELEMENTDATA），此时直接扩容到默认容量10，不走 1.5 倍逻辑 - 后续扩容：按
newCapacity = oldCapacity + (oldCapacity >> 1)计算，即 ×1.5（如 10→15，15→22，22→33） - 但有个硬约束：若算出的
newCapacity仍小于实际所需最小容量（比如当前 size=10，要加 100 个，minCapacity=110），则直接取minCapacity，跳过 1.5 倍——这是addAll()高效的关键 - 上限兜底：若新容量超过
Integer.MAX_VALUE - 8（即MAX_ARRAY_SIZE），会进hugeCapacity()处理，防止溢出崩溃
为什么选 1.5 倍而不是 2 倍或 1.1 倍？
这不是拍脑袋定的，是空间与时间的工程权衡结果：
- 选 2 倍：扩容次数少，但内存浪费严重——比如从 10 扩到 20，只存了 11 个元素，近一半空间闲置；还容易在大容量时触达 JVM 数组长度上限
- 选 1.1 倍：内存友好，但扩容太频繁——插入 1000 个元素可能触发 40+ 次扩容，每次都要
Arrays.copyOf()，开销叠加成性能瓶颈 - 1.5 倍折中：均摊下来单次
add()时间复杂度仍是O(1)，同时避免明显浪费（比如 10→15→22→33→49…，增长平缓可控）
如何避免扩容拖慢性能？
最有效的办法不是改源码，而是“提前说清楚你要装多少”：
- 知道大概数量？直接用带参构造：
new ArrayList(1024)，一步到位，零扩容 - 数据来自外部集合？优先用
new ArrayList(collection)构造器，它会把collection.size()当作初始容量（注意：不是所有Collection的size()都是O(1)，但ArrayList、HashSet等主流实现都是） - 不确定但有下限？用
ensureCapacity(int minCapacity)主动申请，比如循环前先list.ensureCapacity(500)，比边加边扩更省 - 别在循环里反复
new ArrayList()：对象创建+潜在扩容+GC，三重开销，复用或预分配更稳
扩容时复制数据到底有多贵？
核心代价在 Arrays.copyOf()，本质是 System.arraycopy() —— 它是 JVM 内部优化的本地方法，但仍是 O(n) 时间操作。影响真实性能的关键点常被忽略：
立即学习“Java免费学习笔记（深入）”；
- 小数据量（elementData 达到几 MB 甚至几十 MB 时，一次扩容可能卡住几十毫秒，尤其在低延迟服务中会暴露为 P99 尖刺
- 复制过程会暂停 GC 线程（STW 相关阶段），大数组复制可能触发老年代晋升或 CMS 并发模式失败
-
trimToSize()虽能缩容，但本身也是O(n)复制，只建议在确认“后续几乎不增删”且内存敏感的场景使用（如导出报表后长期持有） - 真正的大批量写入（如日志聚合、ETL），应考虑分批提交或切换为
StringBuilder、ByteBuffer等更底层的缓冲结构，而非依赖ArrayList自动管理
扩容机制看着简单，但它的每一次触发都牵扯内存布局、GC 行为和 CPU 缓存局部性。很多线上 OutOfMemoryError: Java heap space 或 STW 时间飙升，追根溯源就是没预估好初始容量，让 ArrayList 在关键时刻反复“搬家”。
