如何在 Java 中使用 ArrayList.ensureCapacity() 减少由于频繁增删导致的数组重分配

首页

编程语言

热心网友

转载

2026-05-01

如何在 Ja va 中使用 ArrayList.ensureCapacity() 减少由于频繁增删导致的数组重分配

免费影视、动漫、音乐、游戏、小说资源长期稳定更新！ 👉 点此立即查看 👈

ensureCapacity() 真的能减少重分配吗？

答案是肯定的，但这里有个关键前提：它只对“新增”操作有效，而且必须在执行大量 add() 之前就调用。至于 remove() 操作，这个方法完全帮不上忙，它也不会主动回收已经分配出去的空间。道理很简单，ArrayList 内部的数组扩容，只在 add() 发现容量不够时才会触发。而 ensureCapacity() 的作用，就是提前把底层的 elementData 数组扩大到指定尺寸，从而避免后续多次的 resize 操作——要知道，每次 resize 都意味着分配新数组和拷贝全部元素，这可是 O(n) 级别的开销。

这里有个常见的误解：有人以为调用一次 ensureCapacity(100)，之后即使删除了90个元素，内存也会自动缩回来。其实不然。ArrayList 的设计决定了它从不自动缩小底层数组，想释放冗余内存，得靠另一个方法 trimToSize()。而且，这也不属于“减少重分配”的范畴，而是纯粹的内存回收行为。

什么时候调用 ensureCapacity() 才真正省开销？

最典型的场景，就是那种“可预估最终规模的批量构建”。比如，从数据库里查询出5000条记录逐条添加，或者解析一个已知长度的JSON数组。在这种情况下，于循环开始前调用 ensureCapacity()，就能完美避免多次扩容。想想看，默认初始容量只有10，按1.5倍的策略扩容，要装下5000个元素，中间至少得经历大约12次数组拷贝，这个开销可不小。

✅ 推荐场景：已知最终的元素数量（比如在 list.size() == expectedSize 成立之前），并且主要操作是 add()。
❌ 无效场景：一边添加一边删除、或者进行随机位置的插入（add(int index, E) 虽然可能引发数组元素移动，但不会触发扩容逻辑）。
⚠️ 特别注意：ensureCapacity() 的参数是“最小需要容量”，而非“精确容量”。传入100，只保证数组长度不小于100；如果当前容量已经大于等于100，那这个方法就什么都不做。

和构造函数 initialCapacity 比，有啥区别？

从本质上讲，两者目的相同，都是设置初始数组大小。区别在于时机：new ArrayList(100) 在对象实例化时就分配好了数组；而 ensureCapacity(100) 则是对已经存在的实例进行“事后补救”。两者的实际性能差异微乎其微，但使用时机不同，能让代码语义更清晰：

如果在构造时就已经清楚知道数据规模，直接用 new ArrayList(initialCapacity)。
如果实例已经存在，稍后才确定要装入大量数据，那就用 ensureCapacity()。
需要明确的是，无论哪种方式，都只影响底层数组的物理容量，而不改变 size() 返回的逻辑元素个数。调用之后，size() 依然是0。

来看一个具体例子：

ArrayList list = new ArrayList<>();
list.ensureCapacity(5000); // 底层数组现在至少长 5000
for (int i = 0; i < 5000; i++) {
    list.add("item" + i); // 全程无 resize
}

容易被忽略的坑：ensureCapacity() 不解决并发和结构性修改问题

即使你精准地调用了 ensureCapacity()，下面这些情况依然可能引发意外的性能开销甚至异常：

多线程同时 add()：即使容量充足，非线程安全的 ArrayList 也可能因竞争导致重复扩容。
使用迭代器或条件删除：通过 list.iterator().remove() 或 removeIf() 删除大量元素后，底层数组容量不变，但后续的 add() 仍会基于当前的 size() 判断扩容，可能造成严重的空间浪费。
清空后复用：调用 clear() 后继续添加，虽然底层数组没变，但 size 已归零。如果之后只加几十个元素，那么之前预分配的5000容量就成了闲置内存。