数组列表在内部使用数组对象来添加(或存储)对象 元素。换句话说，ArrayList由Array数据支持 结构。ArrayList的数组是可调整大小的(或动态的)。

Array比ArrayList快，因为ArrayList内部使用数组。如果我们可以直接在数组中添加元素，而间接地在数组中添加元素 数组通过数组列表总是直接机制比间接机制快。

在ArrayList类中有两个重载的add()方法:

add(Object):将一个对象添加到列表末尾。 add(int index, Object):将指定对象插入到列表的指定位置。

数组列表的大小如何动态增长?

public boolean add(E e)        
{       
     ensureCapacity(size+1);
     elementData[size++] = e;         
     return true;
}

An important point to note from the above code is that we are checking the capacity of the ArrayList, before adding the element. ensureCapacity() determines what is the current size of occupied elements and what is the maximum size of the array. If the size of the filled elements (including the new element to be added to the ArrayList class) is greater than the maximum size of the array then increase the size of the array. But the size of the array can not be increased dynamically. So what happens internally is new Array is created with the capacity

到 Java 6

int newCapacity = (oldCapacity * 3)/2 + 1;

(更新)来自Java 7

 int newCapacity = oldCapacity + (oldCapacity >> 1);

此外，旧数组中的数据被复制到新数组中。

数组列表中有开销方法这就是为什么数组比数组列表快。

A List更灵活....所以List比array更好

更新:

正如Mark所指出的那样，在JVM预热之后(几次测试通过)没有明显的差异。检查与重新创建的数组，甚至新传递开始的新行矩阵。有很大的可能性，这表明简单数组的索引访问不用于有利于集合。

前1-2次简单数组还是快2-3倍。

原来的帖子:

对这个主题来说，太多的词太简单了。毫无疑问，数组比任何类容器都快几倍。我在这个问题上为我的性能关键部分寻找替代方案。下面是我为检查实际情况而构建的原型代码:

import java.util.List;
import java.util.Arrays;

public class IterationTest {

    private static final long MAX_ITERATIONS = 1000000000;

    public static void main(String [] args) {

        Integer [] array = {1, 5, 3, 5};
        List<Integer> list = Arrays.asList(array);

        long start = System.currentTimeMillis();
        int test_sum = 0;
        for (int i = 0; i < MAX_ITERATIONS; ++i) {
//            for (int e : array) {
            for (int e : list) {
                test_sum += e;
            }
        }
        long stop = System.currentTimeMillis();

        long ms = (stop - start);
        System.out.println("Time: " + ms);
    }
}

这就是答案:

基于数组(第16行是活动的):

Time: 7064

根据列表(第17行是活动的):

Time: 20950

还有关于“更快”的评论吗?这是可以理解的。问题是什么时候大约3倍的速度比List的灵活性更好。但这是另一个问题。 顺便说一下，我也根据手工构造的数组列表检查了这个。几乎是一样的结果。

List是java 1.5及以上版本的首选方式，因为它可以使用泛型。数组不能有泛型。数组也有预定义的长度，不能动态增长。初始化一个大数组并不是一个好主意。 ArrayList是用泛型声明数组的方式，它可以动态增长。 但如果删除和插入使用得更频繁，那么链表是使用最快的数据结构。

您应该更喜欢泛型类型而不是数组。正如其他人所提到的，数组是不灵活的，不具有泛型类型的表达能力。(它们确实支持运行时类型检查，但这与泛型类型混在一起很糟糕。)

但是，与往常一样，在优化时，你应该始终遵循以下步骤:

Don't optimize until you have a nice, clean, and working version of your code. Changing to generic types could very well be motivated at this step already. When you have a version that is nice and clean, decide if it is fast enough. If it isn't fast enough, measure its performance. This step is important for two reasons. If you don't measure you won't (1) know the impact of any optimizations you make and (2) know where to optimize. Optimize the hottest part of your code. Measure again. This is just as important as measuring before. If the optimization didn't improve things, revert it. Remember, the code without the optimization was clean, nice, and working.

我猜最初的海报来自c++ /STL背景，这引起了一些混乱。在c++中std::list是一个双链表。

在Java中[Java .util]。List是一个不需要实现的接口(c++术语中的纯抽象类)。List可以是一个双重链表——提供了java.util.LinkedList。然而，100次中有99次，当你想要创建一个新的List时，你想要使用java.util.ArrayList来代替，这是c++ std::vector的大致等价。还有其他标准实现，比如java.util.Collections.emptyList()和java.util.Arrays.asList()返回的那些。

从性能的角度来看，不得不通过一个接口和一个额外的对象会有很小的影响，但是运行时内联意味着这很少有任何意义。还要记住String通常是一个对象加数组。所以对于每个元素，你可能有两个其他的对象。在c++ std::vector<std::string>中，虽然按值复制而不使用指针，但字符数组将形成一个string对象(通常不会共享这些对象)。

如果这段代码对性能非常敏感，那么可以为所有字符串的所有字符创建一个char[]数组(甚至byte[])，然后创建一个偏移量数组。IIRC，这是javac的实现方式。