16

我的直觉说数组比数组列表更快，因为数组列表是使用在填充/丢失元素时调整大小的数组实现的。

我只是想确认这是否属实，这意味着如果您知道要保存的元素数量，就没有理由使用数组列表。

4

8 回答 8

28

任何性能差异都可以忽略不计，特别是如果您使用initialCapacity. 以使其最易读和可维护的任何方式编写您的代码，并尽量不要优化这样的东西，除非您通过测试确定您从中获得了显着的性能影响。

使用的潜在原因ArrayList：

  • 有用的方法（contains等）
  • 实现Iterable、Collection和List，因此可以在许多基于接口的 API 调用中使用。
  • 即使您目前“知道”您的收藏大小永远不会改变，但生活对我们提出了意想不到的要求。当没有明显的优势可获时，为什么要将自己锁定在一种模式中？
于 2012-07-23T23:01:00.013 回答
7

ArrayList 为您提供了许多原始数组所没有的功能。如果您知道元素的数量，则可以创建该大小的 ArrayList。

new ArrayList<String>(100);

如果您担心 ArrayList 和数组之间的速度差异，那么您担心的是错误的事情。它极不可能成为代码中的瓶颈。如果是这样，几乎肯定有比更改为数组更好的答案。

不要屈服于过早的优化。它会对你的代码造成严重破坏。大多数事情都不重要，只有少数事情重要。你只能通过分析你的代码来找到那几件事。试图使每个部分都快是使整体快的一种非常无效的方法。保持干净、简单的设计更有效。这将为您在实际需要的一两个地方引入优化提供必要的接缝。

于 2012-07-23T23:13:07.607 回答
2

ArrayList在简单的获取/设置中不能更快，但差异会非常小，在几乎任何现实情况下都可能不值得担心。

API 有一些你可能需要的List方法，即使你已经知道大小是固定的。contains()例如思考。即使您知道列表的大小是固定的，您也必须ArrayList在需要一个Iterator或 API的情况下使用 -- 再次。List

于 2012-07-23T23:04:33.583 回答
2

正如其他人已经说过的，使用 ArrayList 除非性能基准表明它是一个瓶颈。

是的，由于访问器开销，存在性能差异，这通常不会显着。该一般规则的一个例外是，如果您将原始类型存储在 ArrayList 中。这将再次对性能造成重大影响，因为它将对象转换为对象和原始类型/从对象和原始类型转换。

// easier to work with but slow
ArrayList<Double> slowList;

// faster primitive data array
double[] fasterList;
于 2012-07-23T23:29:52.083 回答
1

是的，数组要快得多。如果您运行数值算法，您会看到明显的加速。

但是，对于正常的应用程序而言，您不必担心它。这是因为无论如何，大部分运行时都花在做其他事情上。

于 2012-07-23T23:03:11.437 回答
0

您不应该过早优化您的代码，而应使用最适合您的代码的数据结构。正如您所说，经验法则可能是：

  1. 我不知道元素的数量或者它正在改变很多=>列表（不要专注于实现）

  2. 元素的数量是预先已知的 => 数组

于 2012-07-23T23:02:56.033 回答
0

如果您知道数组的大小，请确保它不会扩大或缩小。比使用数组。如果您不知道，数组列表更可取且稳定。对于性能，这是您唯一关心的问题吗？向前走..

于 2012-07-23T23:03:04.253 回答
-2

数组比数组列表快得多。差异可能有数百个百分点，并且可能来自 JVM 优化。如果您将数组变量声明为 volatile，您将获得类似的性能。

于 2016-11-28T10:14:15.423 回答