比较ArrayList与LinkedList在随机访问与增删效率

ArrayList与LinkedList：选对数据结构，性能提升不止一点点

在Ja va集合框架里，ArrayList和LinkedList这对“老搭档”常常让人纠结。简单来说：如果你需要频繁地按位置查找元素，ArrayList是你的首选；如果你的操作集中在列表头部或中间进行增删，那么LinkedList往往更胜一筹。这背后的根本原因，在于它们截然不同的底层实现。

一句话概括：ArrayList适合频繁随机访问，LinkedList适合频繁在头部或中间插入删除。

随机访问效率：ArrayList快，LinkedList慢

为什么随机访问差距这么大？关键在于底层。ArrayList的底牌是一个动态数组。当你调用get(500)时，它可以直接通过索引计算出元素在内存中的确切地址，一步到位，时间复杂度是稳稳的O(1)。这个过程不依赖任何其他元素，效率极高。

反过来看LinkedList，它的基础是双向链表。元素在内存中并非连续存放，而是通过节点前后连接。因此，执行get(i)时，它没法“跳转”，只能老老实实地从头部（或尾部，取决于哪个更近）开始，沿着指针一个个“数”过去。平均需要遍历一半的列表长度，时间复杂度是O(n)。即便索引i已经很靠近末尾，这个查找过程也依然是线性的。

尾部增删：两者都较快，但ArrayList可能有扩容开销

在列表末尾进行操作，两者表现都不错，但细节上有差异：

• ArrayList.add(e)：通常情况下是O(1)。不过，一旦数组容量不足，就需要触发扩容——创建一个更大的新数组，并把旧数据全部复制过去。这次扩容操作本身是O(n)的。当然，从均摊成本看，整体效率仍是O(1)，但单次插入可能遭遇明显的性能波动。
• LinkedList.add(e)：在尾部插入一个新节点，只需调整尾节点的指针并新建节点，操作稳定在O(1)。
• 删除末尾元素：两者都很高效。ArrayList直接减小size标识，LinkedList则调整尾指针，都是O(1)。

所以，如果只在尾部操作，两者区别不大，但ArrayList的扩容是一个潜在的性能风险点。

头部或中间增删：LinkedList明显占优

一旦操作位置移到列表前端或中间，形势就逆转了。比如在索引0的位置插入或删除元素：

• ArrayList 就麻烦了。它必须将后续的所有元素都向后移动（插入时）或向前移动（删除时）一个位置。这个操作的时间复杂度是O(n)，列表越长，开销越大。
• LinkedList 则轻松许多。它只需要修改头节点及其相邻节点的指针引用，这个纯粹的链表操作部分是O(1)。不过要注意，如果使用的是add(index, e)这类需要指定索引的方法，它首先需要遍历找到那个位置的节点（O(n)），所以整体仍是O(n)，但找到后的插入动作本身非常轻量。

在中间位置（例如列表正中）插入也是如此：ArrayList平均需要移动约一半的元素；LinkedList虽然也要先遍历到那个位置（O(n)），但随后的节点插入操作，其开销远小于数组元素的大规模搬移。

内存与缓存友好性：ArrayList更优

除了时间复杂度，内存布局对实际性能的影响至关重要。ArrayList的元素在内存中是连续存储的。这种结构对CPU缓存极其友好，当遍历数组时，计算机会预加载连续的内存块，使得访问速度非常快。

而LinkedList的每个节点都分散在堆内存的不同位置，节点本身除了存储数据，还额外包含指向前后节点的引用。这种非连续的内存访问模式，导致CPU缓存命中率很低，频繁的指针跳转会带来大量的缓存未命中。因此，在实际运行中，尤其是遍历操作，LinkedList的表现常常比其理论时间复杂度所暗示的还要慢。

所以说，选择哪一个，绝不能只看理论上的“大O”，还得结合具体的操作场景和计算机底层的工作原理来综合判断。