这取决于你如何访问它。

存储后，如果你主要想做搜索操作，很少或不需要插入/删除，那么就去数组(因为在数组中搜索是在O(1)中完成的，而添加/删除可能需要重新排序元素)。

存储之后，如果你的主要目的是添加/删除字符串，很少或没有搜索操作，那么就去List。

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

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

使用哪一种取决于问题本身。我们得看看大O。

图片来源:https://github.com/egonSchiele/grokking_algorithms

更新:

正如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)。但如果数字变化太大，那么你最好使用LinkedList。 如果有(或将会)需要在中间添加或删除元素，那么你当然必须使用LinkedList。

这里给出的许多微基准测试发现，像array/ArrayList读取这样的事情需要几纳秒。如果所有内容都在L1缓存中，这是非常合理的。

更高级别的缓存或主存访问的数量级可能是10nS-100nS，而L1缓存的数量级更接近1nS。访问ArrayList有一个额外的内存间接，在实际的应用程序中，你可以几乎从不或每次都支付这个代价，这取决于你的代码在访问之间所做的事情。当然，如果你有很多小的数组列表，这可能会增加你的内存使用，使你更有可能缓存丢失。

原来的海报似乎只使用一个，在短时间内访问了很多内容，所以应该没有太大的困难。但是对于其他人来说可能有所不同，在解释微基准测试时应该注意。

Java Strings, however, are appallingly wasteful, especially if you store lots of small ones (just look at them with a memory analyzer, it seems to be > 60 bytes for a string of a few characters). An array of strings has an indirection to the String object, and another from the String object to a char[] which contains the string itself. If anything's going to blow your L1 cache it's this, combined with thousands or tens of thousands of Strings. So, if you're serious - really serious - about scraping out as much performance as possible then you could look at doing it differently. You could, say, hold two arrays, a char[] with all the strings in it, one after another, and an int[] with offsets to the starts. This will be a PITA to do anything with, and you almost certainly don't need it. And if you do, you've chosen the wrong language.