更新:

正如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的灵活性更好。但这是另一个问题。 顺便说一下，我也根据手工构造的数组列表检查了这个。几乎是一样的结果。

这取决于实现。基元类型数组可能比ArrayList更小更高效。这是因为数组将直接将值存储在一个连续的内存块中，而最简单的ArrayList实现将存储指向每个值的指针。特别是在64位平台上，这可能会产生巨大的差异。

当然，对于这种情况，jvm实现有可能有一个特殊情况，在这种情况下，性能将是相同的。

在存储字符串对象的情况下，数组还是列表的选择并不那么重要(考虑到性能)。因为数组和列表存储的都是字符串对象引用，而不是实际对象。

如果字符串的数量几乎是常数，则使用数组(或ArrayList)。但如果数字变化太大，那么你最好使用LinkedList。 如果有(或将会)需要在中间添加或删除元素，那么你当然必须使用LinkedList。

我写了一个比较数组列表和数组的基准测试。在我的老式笔记本电脑上，遍历5000个元素的数组列表1000次的时间比等效的数组代码慢了大约10毫秒。

所以，如果你什么都不做，只是迭代列表，而且你做了很多，那么也许它值得优化。否则，我会使用列表，因为当你需要优化代码时，它会让你更容易。

注意:我确实注意到，使用for String s: stringsList比使用老式的for循环访问列表要慢50%左右。去图…这是我计时的两个函数;数组和列表由5000个随机(不同的)字符串填充。

private static void readArray(String[] strings) {
    long totalchars = 0;
    for (int j = 0; j < ITERATIONS; j++) {
        totalchars = 0;
        for (int i = 0; i < strings.length; i++) {
            totalchars += strings[i].length();

        }
    }
}

private static void readArrayList(List<String> stringsList) {
    long totalchars = 0;
    for (int j = 0; j < ITERATIONS; j++) {
        totalchars = 0;
        for (int i = 0; i < stringsList.size(); i++) {
            totalchars += stringsList.get(i).length();
        }
    }
}

首先，有必要澄清一下，您是指经典的compp sci数据结构意义上的“列表”(即链表)，还是指java.util.List?如果你指的是java.util。List，它是一个接口。如果你想使用数组，只要使用数组列表实现，你就会得到类似数组的行为和语义。问题解决了。

如果你指的是数组和链表，这是一个稍微不同的参数，我们回到大O(如果这是一个不熟悉的术语，这里有一个简单的英语解释。

数组;

随机存取:O(1); 插入:O (n); 删除:O (n)。

链表:

随机存取:O(n); 插入:O (1); 删除:O(1)。

你可以选择最适合调整数组大小的方法。如果你调整大小，插入和删除很多，那么链表可能是一个更好的选择。如果随机访问很少，情况也是如此。你提到了串行访问。如果你主要做串行访问，很少修改，那么你选择哪一个可能都不重要。

链表的开销略高，因为正如您所说，您正在处理潜在的不连续内存块和(有效地)指向下一个元素的指针。但是，除非您要处理数百万个条目，否则这可能不是一个重要因素。

如果你有几千个，考虑使用trie。trie是一种树状结构，它合并了存储字符串的公共前缀。

例如，如果字符串是

intern
international
internationalize
internet
internets

该树将存储:

intern
 -> \0
 international
 -> \0
 -> ize\0
 net
 ->\0
 ->s\0

字符串需要57个字符(包括空结束符'\0')来存储，再加上存储它们的String对象的大小。(事实上，我们可能应该四舍五入到16的倍数，但是……)粗略地称它为57 + 5 = 62字节。

这个trie需要29个存储空间(包括空结束符'\0')，加上对trie节点的sizeof，这些节点是一个数组的引用和一列子trie节点。

在这个例子中，结果可能是一样的;对于成千上万的人来说，只要你有共同的前缀，它可能会更少。

现在，在其他代码中使用trie时，必须转换为String，可能使用StringBuffer作为中介。如果在trie之外，同时使用了许多字符串作为字符串，这是一种损失。

但如果你一次只使用几个——比如，在字典中查找东西——trie可以为你节省很多空间。绝对比存储在HashSet中的空间要小。

你说你是“连续地”访问它们——如果这意味着按字母顺序访问，如果你深度优先迭代，trie显然也会免费给你字母顺序。