ArrayList扩容机制：从源码细节到工程实践
一、先把两个概念分清楚：size 和 capacity
聊 ArrayList 扩容之前，先区分两个容易混淆的概念：
size：当前列表中实际存放的元素个数。capacity：底层数组elementData的长度，也就是当前最多能容纳多少个元素而不触发扩容。
这两个值不是一回事。
List<String> list = new ArrayList<>(100);
list.add("A");System.out.println(list.size()); // 1
这段代码里，size() 返回的是 1，因为列表里只有一个元素。但底层数组的容量是 100。日常开发中我们通常只能直接看到 size，看不到 capacity，这也是很多人误解 ArrayList 初始化和扩容机制的原因。
理解这两个概念后，再看 ArrayList 的初始化和扩容，就会清楚很多。
二、ArrayList 的底层结构
2.1 elementData：真正存储元素的数组
ArrayList 底层通过数组存储元素。数组字段在源码中通常叫 elementData，类型是 Object[]。
简化理解如下：
transient Object[] elementData;
private int size;
elementData：底层数组，负责保存元素引用。size：当前已经存储的元素个数。
ArrayList 支持按下标快速访问，本质上就是数组随机访问的能力：
String value = list.get(10);
只要下标合法，get(index) 可以直接通过数组下标定位元素。但数组的缺点也很明显：长度固定，容量不够时不能在原数组上直接变长，只能创建一个更大的新数组，再把旧数组中的元素复制过去。
这就是 ArrayList 扩容机制的基础。
2.2 DEFAULT_CAPACITY：默认容量不是构造时立即分配
很多文章会说：ArrayList 默认容量是 10。
这个说法不算完全错，但容易误导。更准确的说法是：
也就是说，DEFAULT_CAPACITY = 10 表示“首次写入时的默认容量”，不是“无参构造完成后立即拥有长度为 10 的数组”。
2.3 为什么要延迟初始化
延迟初始化的好处是减少无意义的内存占用。
在后端系统中，一个对象里可能会有多个集合字段：
public class OrderContext {
private List<String> validationErrors = new ArrayList<>();
private List<String> warnings = new ArrayList<>();
private List<String> operationLogs = new ArrayList<>();
}
如果每个 new ArrayList<>() 都立即分配长度为 10 的数组，而这些列表大多数时候并不会写入元素，就会产生不必要的内存浪费。
所以 ArrayList 采用延迟分配：先用空数组占位，真正添加元素时再分配容量。
三、初始化容量：无参构造和有参构造的区别
3.1 无参构造：初始容量为 0，首次 add 扩到 10
常见写法如下：
List<String> list = new ArrayList<>();
这种方式创建出来的 ArrayList，在没有添加元素之前，底层数组并不会分配 10 个槽位。第一次执行 add 时，才会触发容量初始化。
List<String> list = new ArrayList<>();
list.add("A"); // 首次添加时触发扩容，容量通常变为 10
这里要注意：
list.size()是 1。- 底层数组容量通常是 10。
- 10 是默认容量，不是当前元素个数。
3.2 有参构造：按指定容量创建数组
如果能预估列表规模，可以使用有参构造：
List<Long> userIds = new ArrayList<>(1000);
这表示底层数组一开始就按容量 1000 创建，后续添加元素只要不超过 1000，就不会触发扩容。
这种写法适合列表规模比较明确的场景，例如：
- 数据库查询结果转换为 DTO；
- 批量消息消费后组装处理结果；
- RPC 或 HTTP 接口返回列表后做二次加工；
- 从已有集合中映射出另一个集合。
例如：
List<UserDTO> result = new ArrayList<>(users.size());
for (User user : users) {
result.add(toDTO(user));
}
如果 users.size() 已经明确，提前指定容量可以减少扩容次数，也能让代码表达出“结果列表规模与源列表一致”的意图。
3.3 不要盲目设置过大的初始容量
预分配容量不是越大越好。
List<String> list = new ArrayList<>(1000000);
如果最终只放入几十个元素，这个数组的大部分空间都会闲置。对于高并发服务，这类过度预分配可能放大堆内存压力，甚至增加 GC 负担。
比较稳妥的原则是：
- 能明确预估规模时，指定合理初始容量；
- 无法预估规模时，使用默认构造即可；
- 对可能很大的列表，要考虑分页、流式处理或分批处理，而不是单纯扩大
ArrayList容量。
四、add 操作的扩容流程
4.1 第一次 add：从空数组扩到默认容量
使用无参构造时：
List<Integer> numbers = new ArrayList<>();
numbers.add(1);
第一次 add 会发现当前底层数组容量不足，于是触发扩容。对于 JDK 8/11 常见实现，首次扩容容量通常是 10。
可以理解为：
当前容量 = 0
新增 1 个元素后所需最小容量 = 1
无参构造使用默认容量规则
最终容量 = max(10, 1) = 10
4.2 超过当前容量后，按 1.5 倍尝试扩容
当列表已经有 10 个元素，再添加第 11 个元素时，当前容量不够，需要扩容。
ArrayList 的新容量计算逻辑可以简化理解为：
int newCapacity = oldCapacity + (oldCapacity >> 1);
oldCapacity >> 1 表示旧容量右移一位，相当于取旧容量的一半。因此新容量约等于旧容量的 1.5 倍。
例如：
旧容量 10 -> 新容量 15
旧容量 15 -> 新容量 22
旧容量 22 -> 新容量 33
这里不是用浮点数乘以 1.5，而是使用整数运算。所以当旧容量是 15 时：
15 + (15 >> 1) = 15 + 7 = 22
这也是为什么扩容结果不是 22.5，而是 22。
4.3 1.5 倍不够时，直接扩到所需最小容量
如果一次性新增很多元素，1.5 倍扩容可能仍然不够。
例如当前容量是 10，当前 size 是 10，此时一次性需要容纳 100 个元素，那么最小所需容量是 100。按 1.5 倍只能扩到 15，显然不够。
这种情况下，新容量会直接取所需最小容量。
旧容量 = 10
1.5 倍后容量 = 15
最小所需容量 = 100
最终新容量 = 100
这个规则在 addAll 场景中特别常见。
4.4 扩容的本质：创建新数组并复制元素
数组长度固定，扩容不是在原数组上直接变长，而是：
- 创建一个更大的新数组；
- 把旧数组中的元素复制到新数组；
- 将
elementData指向新数组； - 旧数组如果没有其他引用，后续由 GC 回收。
简化理解如下：
Object[] oldArray = elementData;
Object[] newArray = Arrays.copyOf(oldArray, newCapacity);
elementData = newArray;
这意味着扩容会带来两类成本：
- CPU 成本：复制旧数组元素；
- 内存成本：扩容瞬间新旧数组可能同时存在，形成短时间的内存峰值。
对于小列表，这个成本通常可以忽略。对于大列表，尤其是高并发接口中频繁构建大集合时，这个成本就需要关注。
五、addAll 操作的扩容规则
5.1 空集合 addAll：容量取默认容量和新增元素数的较大值
看一个例子：
List<Integer> source = Arrays.asList(1, 2, 3, 4, 5);
List<Integer> target = new ArrayList<>();target.addAll(source);
target 是无参构造的空集合，第一次 addAll 时，新增元素个数是 5。此时底层容量通常会扩到 10。
可以理解为：
新增元素数 = 5
默认容量 = 10
最终容量 = max(10, 5) = 10
如果新增元素超过 10：
List<Integer> source = new ArrayList<>(20);
for (int i = 0; i < 20; i++) {
source.add(i);
}List<Integer> target = new ArrayList<>();
target.addAll(source);
此时所需最小容量是 20，超过默认容量 10，因此目标列表会直接扩到 20。
新增元素数 = 20
默认容量 = 10
最终容量 = max(10, 20) = 20
5.2 非空集合 addAll：容量至少满足 size + numNew
对于非空集合，addAll 的核心是先计算最小所需容量：
最小所需容量 = 当前 size + 新增元素数量
例如：
List<Integer> target = new ArrayList<>(10);
for (int i = 0; i < 10; i++) {
target.add(i);
}List<Integer> source = Arrays.asList(10, 11, 12, 13, 14);
target.addAll(source);
此时：
当前 size = 10
新增元素数 = 5
最小所需容量 = 15
旧容量是 10，按 1.5 倍扩容后正好是 15，所以新容量为 15。
如果新增元素更多：
List<Integer> target = new ArrayList<>(10);
for (int i = 0; i < 10; i++) {
target.add(i);
}List<Integer> source = new ArrayList<>(100);
for (int i = 0; i < 100; i++) {
source.add(i);
}target.addAll(source);
此时：
当前 size = 10
新增元素数 = 100
最小所需容量 = 110
1.5 倍扩容结果 = 15
最终容量 = 110
因为 15 无法容纳 110 个元素，所以新容量直接取 110。
5.3 批量添加前更应该关注容量
addAll 通常出现在批量处理场景中：
- 合并多个接口返回的结果；
- 聚合多个数据库查询结果；
- 批量消费消息后收集处理结果；
- 将多个分组数据汇总成一个列表。
如果能提前知道总数量，可以直接指定容量：
List<OrderDTO> allOrders = new ArrayList<>(paidOrders.size() + unpaidOrders.size());
allOrders.addAll(paidOrders);
allOrders.addAll(unpaidOrders);
这段代码有两个好处：
- 避免
addAll过程中多次扩容； - 让读者一眼看出结果列表容量与两个源集合之和有关。
这种写法不是为了追求“极致性能”，而是用很低的代码成本减少不必要的数组复制，并提升代码意图的清晰度。
六、工程实践：什么时候需要提前指定容量
6.1 从已有集合映射新集合
这是最典型的预分配场景。
public List<UserDTO> convert(List<User> users) {
List<UserDTO> result = new ArrayList<>(users.size());
for (User user : users) {
result.add(new UserDTO(user.getId(), user.getName()));
}
return result;
}
如果 result 的数量与 users 基本一致，使用 users.size() 作为初始容量是合理的。
在 Java Stream 中，也可以写得更简洁，但普通循环在一些性能敏感路径中更容易控制容量和调试过程。
6.2 数据库分页结果转换
后端服务中常见写法是查询一页数据后转换为 VO/DTO：
public List<OrderVO> buildOrderVOList(List<OrderDO> records) {
List<OrderVO> result = new ArrayList<>(records.size());
for (OrderDO record : records) {
result.add(toOrderVO(record));
}
return result;
}
这里列表大小通常不会超过分页大小，容量比较容易估算，适合提前指定。
不过，如果一次查询可能返回非常大的结果集，更重要的问题不是 ArrayList 扩容，而是是否应该分页、限流或流式处理。
6.3 消息批处理结果收集
批量消费消息时，经常需要收集处理成功或失败的结果：
public List<MessageResult> handleBatch(List<Message> messages) {
List<MessageResult> results = new ArrayList<>(messages.size());
for (Message message : messages) {
results.add(handleOne(message));
}
return results;
}
这种场景下，结果数量通常和输入消息数量一致，预分配容量可以减少扩容，也能让代码表达更明确。
6.4 不适合提前分配大容量的场景
以下场景不建议盲目设置大容量：
- 结果数量无法预估；
- 大多数请求只会产生少量元素；
- 列表可能长期持有，过大容量会造成内存浪费；
- 高并发路径中每次请求都创建大容量列表；
- 更合理的方案是分页、分批、流式处理，而不是一次性装入内存。
例如：
// 不建议在没有依据的情况下这么写
List<String> logs = new ArrayList<>(100000);
如果每个请求都创建这样的列表，即使只写入少量元素，也会造成明显的内存浪费。
七、常见坑与线上排查思路
7.1 把 size 当成 capacity
list.size() 只能说明当前元素个数，不能说明底层数组容量。
List<String> list = new ArrayList<>(1000);
list.add("A");System.out.println(list.size()); // 1
这里不能因为 size() 是 1，就认为底层数组容量也是 1。
在业务代码中通常不需要直接获取 ArrayList 的底层容量。更重要的是在构建大列表时，思考是否能合理预估容量。
7.2 频繁扩容带来的数组复制
如果不断向列表中添加元素，而没有指定初始容量，ArrayList 会按规则多次扩容。
List<Long> ids = new ArrayList<>();
for (long i = 0; i < 100000; i++) {
ids.add(i);
}
这段代码不一定有问题，但如果它位于高频调用链路中，就要关注扩容带来的额外数组复制。
更好的写法是：
int expectedSize = 100000;
List<Long> ids = new ArrayList<>(expectedSize);
for (long i = 0; i < expectedSize; i++) {
ids.add(i);
}
如果数据量来自分页大小、批处理大小或源集合大小，优先使用这些已有信息作为容量依据。
7.3 ArrayList 不是线程安全容器
ArrayList 的扩容和写入操作不是线程安全的。多个线程同时修改同一个 ArrayList，可能导致数据丢失、状态不一致，甚至出现难以复现的问题。
不建议这样写：
List<Integer> list = new ArrayList<>();// 多线程同时 add 同一个 ArrayList，存在并发安全问题
parallelTasks.forEach(task -> list.add(task.getId()));
如果确实需要多线程收集结果，可以根据场景选择：
- 使用线程内局部列表，最后单线程合并；
- 使用
Collections.synchronizedList(new ArrayList<>())； - 读多写少场景考虑
CopyOnWriteArrayList，但要注意写入复制成本； - 使用并发队列，例如
ConcurrentLinkedQueue，再按需转换为列表。
更推荐先从业务流程上避免多个线程共享可变列表。
7.4 如何排查列表膨胀或内存问题
当线上出现内存占用升高、GC 频繁、接口响应变慢时，如果怀疑和大列表有关，可以从以下方向排查：
- 看调用链路：是否有接口一次性查询过多数据并放入
ArrayList。 - 看分页限制：是否缺少分页、limit 或批处理上限。
- 看对象大小：列表里存的是轻量 ID，还是包含大量字段的大对象。
- 看生命周期：列表是方法内临时对象，还是被缓存、上下文对象、静态变量长期持有。
- 看 GC 日志和堆转储：是否存在大量
Object[]、业务 DTO、集合对象占用内存。 - 看可观测性指标：接口耗时、返回条数、批处理大小、失败重试次数是否异常放大。
需要注意，ArrayList 本身通常不是问题根源。真正的问题往往是：业务代码一次性把过多数据装进内存，或者列表生命周期被意外拉长。
八、总结
ArrayList 扩容机制并不复杂，但有几个细节容易被误解：
- 无参构造不会立即分配容量为 10 的数组；
DEFAULT_CAPACITY = 10更准确地说是首次添加元素时的默认容量；size表示元素个数，capacity表示底层数组容量，两者不是一回事；- 扩容通常按
oldCapacity + (oldCapacity >> 1)计算，也就是约 1.5 倍； - 如果 1.5 倍仍不能满足最小所需容量，会直接扩到所需容量；
- 扩容本质是创建新数组并复制旧元素，不是原地修改数组长度；
addAll场景下，应重点关注当前 size + 新增元素数；- 在能预估规模的批量场景中，提前指定容量可以减少不必要的扩容和数组复制。
从工程角度看，理解 ArrayList 扩容不是为了在每一行代码里做微优化，而是为了在批量处理、大结果集转换、高并发接口、内存排查等场景中做出更稳妥的判断。
如果列表规模很小，默认构造通常足够；如果列表规模明确，指定初始容量更合适；如果列表规模可能很大，更应该优先考虑分页、分批、流式处理和生命周期控制。
