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

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

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

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

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

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

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

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

这些是最常用的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)中插入/删除/包含/大小

我认为主要的区别在于你是否经常需要从列表顶部插入或删除内容。

对于一个数组，如果你从列表的顶部移除一些东西复杂度是o(n)因为数组元素的所有下标都要移位。

对于链表，它是o(1)，因为您只需要创建节点，重新分配头，并将对next的引用分配为前一个头。

当经常在列表的末尾插入或删除时，数组是更可取的，因为复杂度将是o(1)，不需要重新索引，但对于链表，它将是o(n)，因为你需要从头到最后一个节点。

我认为在链表和数组中搜索都是o(log n)因为你可能会使用二分搜索。

To add to the other answers, most array list implementations reserve extra capacity at the end of the list so that new elements can be added to the end of the list in O(1) time. When the capacity of an array list is exceeded, a new, larger array is allocated internally, and all the old elements are copied over. Usually, the new array is double the size of the old one. This means that on average, adding new elements to the end of an array list is an O(1) operation in these implementations. So even if you don't know the number of elements in advance, an array list may still be faster than a linked list for adding elements, as long as you are adding them at the end. Obviously, inserting new elements at arbitrary locations in an array list is still an O(n) operation.

访问数组列表中的元素也比访问链表快，即使访问是顺序的。这是因为数组元素存储在连续的内存中，可以很容易地缓存。链表节点可能分散在许多不同的页面上。

如果知道要在任意位置插入或删除项，我建议只使用链表。数组列表在其他方面会更快。