嗯，我猜数组列表可以用在以下情况下:

您无法确定将会出现多少个元素 但是您需要通过索引随机访问所有元素

例如，您需要导入并访问联系人列表中的所有元素(您不知道其大小)

数组具有O(1)随机访问，但是向数组中添加或删除内容的代价非常高。

链表在任何地方添加或删除项目和迭代都非常便宜，但随机访问是O(n)。

如果您需要在中间插入项，并且不想开始调整数组大小和移动内容，则列表的优势就会显现出来。

你是对的，通常情况下并非如此。我遇到过一些非常具体的案例，但不是很多。

Algorithm           ArrayList   LinkedList
seek front            O(1)         O(1)
seek back             O(1)         O(1)
seek to index         O(1)         O(N)
insert at front       O(N)         O(1)
insert at back        O(1)         O(1)
insert after an item  O(N)         O(1)

数组列表适用于写一次读多次或追加程序，但不适用于从前面或中间进行添加/删除。

这些是最常用的Collection实现。

数组列表:

插入/删除在结尾一般O(1)最坏情况O(n) 中间插入/删除O(n) 检索任意位置O(1)

LinkedList:

在任何位置O(1)插入/删除(注意你是否引用了元素) 中间检索O(n) 检索第一个或最后一个元素O(1)

向量:不要用。它是一个类似于ArrayList的旧实现，但所有方法都是同步的。对于多线程环境中的共享列表，这不是正确的方法。

HashMap

在O(1)中按键插入/删除/检索

TreeSet 插入/删除/包含O(log N)

HashSet 在O(1)中插入/删除/包含/大小

在现实中，内存局部性对实际处理的性能有很大的影响。

与随机访问相比，磁盘流在“大数据”处理中的使用越来越多，这表明围绕它构建应用程序可以在更大范围内显著提高性能。

如果存在按顺序访问数组的方法，则这是迄今为止性能最好的方法。如果性能很重要，那么至少应该考虑将此作为设计目标。