ArrayList 很好用，但 LinkedList 并不是它的自然升级版

Java 集合一学到 ArrayList 和 LinkedList，很多人就会形成一个很顺手的印象：前者适合查，后者适合增删，于是当某段代码出现“可能会插入删除”的需求时，就很自然地想把 LinkedList 搬出来。可真到业务代码里，这个选择远没有口诀那么简单。

我后来反而越来越少主动选 LinkedList，不是它没用，而是很多场景并没有真的满足它发挥优势的条件。

两者的差别，别只背成一句口诀

ArrayList 背后是连续存储，随机访问很顺；LinkedList 背后是节点链式连接，理论上某些位置的插入删除更直接。
问题在于，业务代码里的“插入删除”往往不是已经拿着节点就地操作，而是得先找到那个位置。

一旦查找成本也算进来，很多想象中的优势就没那么明显了。

我什么时候还会优先用 ArrayList

如果场景满足下面这些特征，我几乎还是会先用 ArrayList：

• 列表主要用来遍历和读取
• 数据量可控
• 中间插入删除不是高频核心动作
• 更在意遍历性能和内存局部性

这其实覆盖了大量后台业务代码。

LinkedList 更适合什么

我对 LinkedList 的态度更像是：它适合那些确实围绕头尾操作、或者已经天然持有位置引用的场景。
如果只是因为“可能以后会删元素”就提前换成它，往往是在为一个并不确定的优势买单。

真正该问的问题不是“谁更高级”

我后来做集合选择时，更多问的是：

• 这份数据是读多还是改多
• 改动主要发生在头尾还是中间
• 我拿到的是索引还是节点语义
• 列表规模是否长期增长

这些问题一旦问清楚，很多时候答案并不会自动落在 LinkedList 上。

结论

ArrayList 很常见，不代表它只是入门选项；LinkedList 看起来更“灵活”，也不代表它天然更适合复杂场景。
2018 年以后我对集合的理解反而更朴素了：别被数据结构课上的一句话牵着走，先看你手里的业务动作到底长什么样。