为啥越来越多开发说“链表已死”？我做后端5年没觉得啊

楼上说得一半对。链表在现代CPU下缓存不友好是真的，但说它“已死”太绝对了。
有些场景链表的灵活性独一无二，比如：并发无锁队列（用CAS操作链表头尾），数组没法做到O(1)的并发插入。还有嵌入式或实时系统，内存碎片不是问题，链表反而好用。问题在于大部分互联网后端，数据量大且CPU缓存敏感，所以链表被淘汰是趋势。但不能一棍子打死。

共情一下，我也曾经觉得链表贼牛，教科书上说的嘛。但实际项目里，真的很少用纯链表了。
我前年做一个搜索建议的下拉模块，几千个词本来用链表存候选，结果用户打字反馈慢成狗。一分析，内存碎片加缓存不命中，每次查询都在堆里乱跳。换成连续内存的数组+索引，直接起飞。那之后我对链表就粉转黑了，只在面试题里见到它。

这事我也想问呢，为什么教科书还在大讲链表？但合规视角说一句：实际工程里，用链表搞出性能事故的案例太多，面试时候背得溜溜的，一上线CPU报警。如果你系统对延迟敏感，别碰链表。
从我见过的代码审计案例，链表滥用导致的性能问题，比数组出bug的频率高得多。当然如果你想面试时写个反转链表，那全世界都还在用。

你这个数据靠谱吗？后端5年还没觉得链表慢？那可能你还没碰到海量数据场景。
我做电商平台后台，有一回处理几十万条订单缓存，链表插入O(1)看着很美，但实际CPU缓存命中率惨不忍睹。每个节点内存离散，遍历起来CPU得不停去主存搬数据，时间全耗在缓存未命中上。后来换成数组+哈希表，同样功能速度翻了快3倍。链表的“快”在现代CPU面前就是纸上谈兵，真的会谢。

楼主说到LRU缓存，其实现在工业级的LRU根本不用链表了。像Redis那种高性能内存库，用跳表或者紧凑数组做近似LRU，比纯链表省内存还快。你写的那套链表LRU，放到每秒几万QPS的服务里，CPU缓存打爆你。
还是那句话，O(1)复杂度不顶用，你得看Cache Miss Cost。链表每个节点分散在堆里，就像一个个孤立的小岛，CPU寻址要划船。数组是连着的，直接开船过去。

我也亏过，面试时候链表倒背如流，以为自己是高手。结果入职第一周，leader让我优化一个数据管道，一看代码里套了三层链表，他直接说“删了重写，别问我为什么”。
后来才明白，链表就像大学里学的手动挡，技术在进步，自动挡（向量化、SIMD、内存池）才是工程里的主流。别跟CPU过不去，它不喜欢碎片化的内存。

说个自己的例子。去年做个用户行为日志系统，用链表存最近100条操作，想着O(1)插入删除多美啊。上线后监控一看，延迟抖动特别大，平均1毫秒，偶尔冲到10毫秒。查了几天，就是链表遍历时触发了CPU缓存未命中。换成双向队列（底层数组那种），抖动直接消失了。
有时候不是链表不行，是现代CPU的存储架构已经不适合它了。数据量大一点，它就是性能毒药。