为什么现在做技术的都说链表已死？我刚入行还在学，到底还学不学

真没死，就是退居二线当备胎了。我工作前也觉得链表是神，插入删除 O(1) 多牛啊。后来去做推荐系统，数据量上来以后发现，链表最致命的是缓存不友好，每个节点内存乱跳，CPU 预取直接废了。数组加下标它不香吗，连续内存一把梭。
而且现在写业务逻辑，谁还手动撸链表？Java 里有 LinkedList，但实际用的最多的还是 ArrayList。Redis 里倒是有链表，但人家是精心设计的双向链表加压缩列表。面试考链表，考的是你底子扎不扎实，不是让你真去用。
家人们，学还是要学，面试这关绕不过去。但别怕，工作上大概率用不上，用上了也就是调个 API。

我觉得你想反了。不是链表已死，是大部分人用不到链表的场景。你要是写业务 CRUD，别说链表，连树都用不上，一个数组一个哈希表走天下。
我这边的项目是自研的存储引擎，里面大量用链表做版本链和事务 undo log。为啥？因为那些场景需要频繁的插入删除，而且数据量是动态的，没法预先分配连续空间。你要是硬用数组，内存碎片和扩容开销能把性能拖垮。
所以题主你该学的还是好好学，但学的时候多问一句：这结构适合什么场景？缓存友好的代价是什么？理解了这些，面试官问你反而觉得你有深度。别听那些"已死"的论调，说这种话的人大概率只是写多了业务代码。

这个其实没那么复杂，说"链表已死"是指它在业务代码里的直接使用场景在萎缩，不是说这个数据结构本身没价值。
核心原因是内存层级结构的变化。CPU 缓存按 64 字节的 cache line 加载数据，数组的连续内存能让一次预取覆盖多个元素，而链表的节点散落在堆里，访问下一个节点大概率要重新走一次缓存 miss。在追求高吞吐的后端服务里，这个差距被放大到几十倍。
我做过一个统计，把某个核心链路里的链表改成动态数组后，P99 延迟从 45ms 降到了 12ms。这就是现实。但操作系统内核、文件系统、内存分配器里，链表依然是主力，因为它们面对的是更复杂的内存管理场景。
所以结论是：数据结构本身没死，只是它的应用场景从应用层退到了更底层。你学的时候别只背复杂度，要理解它为什么在那层合适，又为什么在这层不合适。