ArrayList中的get（i）操作比LinkedList更快，因为：ArrayList：List接口的可调整大小的数组实现LinkedList：list和Deque接口的双重链接列表实现

索引到列表中的操作将从开始或结束遍历列表，以更接近指定索引的为准。

这取决于您将在列表中执行更多操作。

ArrayList访问索引值更快。插入或删除对象时，情况更糟。

要了解更多信息，请阅读任何关于数组和链接列表之间区别的文章。

ArrayList本质上是一个数组。LinkedList实现为双链接列表。

答案很清楚。O（1）表示ArrayList，因为ArrayList允许使用索引进行随机访问。O（n）表示LinkedList，因为它需要首先查找索引。注意：添加和删除有不同的版本。

LinkedList在添加和删除时速度更快，但在获取时速度较慢。简而言之，在以下情况下，应首选LinkedList：

元素没有大量的随机访问有大量的添加/删除操作

==阵列列表===

添加（E E）在ArrayList末尾添加需要内存大小调整成本。O（n）最差，O（1）摊销add（int索引，E元素）添加到特定索引位置需要移动和可能的内存调整成本O（n）删除（int索引）删除指定的元素需要移动和可能的内存调整成本O（n）删除（对象o）从此列表中删除第一个出现的指定元素需要先搜索元素，然后移动&可能的内存调整成本O（n）

==链接列表===

添加（E E）添加到列表末尾O（1）add（int索引，E元素）在指定位置插入需要先找到位置O（n）删除（）删除列表的第一个元素O（1）删除（int索引）删除具有指定索引的元素需要先找到元素O（n）删除（对象o）删除指定元素的第一个引用需要先找到元素O（n）

这是programcreek.com中的一个图（add和remove是第一种类型，即在列表末尾添加元素，然后在列表中的指定位置删除元素）：

Joshua Bloch，LinkedList的作者：

有人真的使用LinkedList吗？我写的，我从来没有用过。

链接：https://twitter.com/joshbloch/status/583813919019573248

很抱歉，我的答案没有其他答案那样信息丰富，但我认为这是最不言自明的答案。

数组列表本质上是一个具有添加项等方法的数组（您应该使用通用列表）。它是可以通过索引器（例如[0]）访问的项的集合。它意味着从一个项目到下一个项目的进展。

链接列表指定从一个项目到下一个项目（项目A->项目b）的进度。您可以使用数组列表获得相同的效果，但链接列表绝对会说明前一个列表后面应该包含哪些项。

见原始答案下方作者的2021更新。

原答案（2011年）

作为一个在非常大规模的SOA web服务上做了大约十年操作性能工程的人，我更喜欢LinkedList而不是ArrayList的行为。虽然LinkedList的稳态吞吐量更差，因此可能会导致购买更多硬件，但ArrayList在压力下的行为可能会导致集群中的应用程序以近乎同步的方式扩展其阵列，而对于较大的阵列大小，可能会导致应用程序缺乏响应能力，在压力下停机，这是灾难性的行为。

类似地，您可以从默认的吞吐量固定垃圾收集器中获得更好的应用吞吐量，但一旦您获得了具有10GB堆的java应用程序，您就可以在完全GC期间锁定应用程序25秒，这会导致SOA应用程序超时和失败，如果太频繁，还会破坏SLA。尽管CMS收集器占用了更多的资源，并且没有实现相同的原始吞吐量，但它是一个更好的选择，因为它具有更可预测性和更小的延迟。

如果您所指的性能是吞吐量，并且可以忽略延迟，那么ArrayList只是性能的更好选择。根据我的工作经验，我不能忽视最坏情况下的延迟。

更新（2021 8月27日——10年后）

这个答案（也是我在SO问题上最受欢迎的答案）很可能是错误的（原因在下面的评论中概述）。我想补充一点，ArrayList将优化内存的顺序读取，并最小化缓存线和TLB未命中等。相比之下，当阵列增长超过边界时的复制开销可能无关紧要（可以通过高效的CPU操作完成）。考虑到硬件趋势，随着时间的推移，这个答案可能会变得更糟。LinkedList可能有意义的唯一情况是，如果您有数千个列表，其中任何一个都可能增长到GB大小，但在分配列表时无法做出正确的猜测，并且将它们全部设置为GB大小，则会炸毁堆。如果你发现了这样的问题，那么无论你的解决方案是什么，都需要重新设计（我不想轻率地建议重新设计旧代码，因为我自己维护了一堆又一堆的旧代码，但这是一个很好的例子，因为原始设计已经过时，确实需要扔掉）。尽管如此，我还是会把我几十年来的糟糕观点留在那里，让你读一读。简单、合乎逻辑，而且非常错误。