为什么都说「链表已死」？我写了个 LRU 用链表被同事喷了一下午，真没救了吗

去年我优化过一个缓存模块，原同事用的链表存的全局配置，每次热更新要遍历上千个节点去找 key。我当时看了眼代码人都麻了，直接改成 unordered_map + 双 buffer 热切换，更新 O(1)，查询 O(1)，GC 压力还小了。上线后 99 线延迟从 80ms 掉到 25ms，那天我下午 4 点就走人了。
其实现代 CPU 的缓存行是 64 字节，链表节点分散在堆里，你访问一个节点要等一次 cache miss，动辄一两百个周期。数组是连续内存，一次性加载整片到 L2 缓存，速度不是一个量级。高频场景用数组模拟链表或者干脆用 vector 加索引，效果吊打原版链表。
不过也别说链表一无是处，我在某个嵌入式项目里用过 intrusive list，那时候内存是以字节为单位抠的，链表反而最省。关键还是看场景。但楼主你写业务系统用 std::list 当 LRU，被喷很正常，换我我也要喷两句。

楼主这事儿我也想问，2026 年了怎么还有人在业务代码里整链表。我前公司一老哥，为了展示自己懂数据结构，把每个接口的响应都塞进一个双向链表里，美其名曰"方便插入删除"。结果每次请求要遍历整个链表才能找到响应，压测直接崩，他当时就破防了。
说回正事，链表对于 99% 的业务代码确实没卵用。你要是写操作系统、写数据库引擎那另说，但大部分人写个 CRUD 服务，用数组和哈希表就够了。真想学点有用的，不如去研究下 cache-friendly 的数据结构，或者看看内存池怎么搞。链表这东西，应付面试就完了，别当真往生产代码里塞。

楼上说得对一半。链表死了这个说法太绝对，但 LRU 用 std::list 确实不是最优解。
我搞过几年服务端性能优化，2023 年优化过一个网关的 session 缓存，里面就是链表 + hashmap 的经典 LRU。压测 QPS 5000 的时候 CPU 跑到 70%，perf top 一看全是 list 节点的 cache miss。换成 vector 存索引 + 空闲槽位复用，QPS 拉到 15000，CPU 降到 40%。那次优化前后花了两周，性能差距是实打实的。
不过链表在某些场景还是活的。比如内核里的 task_struct 链表，或者无锁队列的 MPSC 实现，因为并发场景下数组搬迁的开销不可控，链表反而是更稳的选择。另外像 Rust 的 LinkedList 虽然有，但文档直接写着 FIXME 说这玩意性能差建议别用。
所以我的看法是：业务代码里碰链表，九成是过度设计或者图省事，性能敏感路径直接用内置容器或者数据结构库更靠谱。但你要说彻底死了那也不至于，底层系统和内核里它还是有一席之地的。