看网上好多技术博主在说链表这种数据结构已经不适合现代计算机了，CPU缓存啥的会把它虐爆。我自己写代码也用得少，但总觉得数组也不是万能的吧？链表到底死在哪儿了？还有翻盘的余地吗？
3 Answers
你确定研究过 Redis 的 list 实现吗？人家早期版本确实是双向链表，但后来都改成 quicklist 了，本质上是压缩列表和链表的混合体。这不正好说明纯链表在现代存储引擎里确实不吃香了？
我 2025 年做的一个订单系统，最开始用链表存待处理队列，后来发现 GC 压力大得离谱。链表节点全是小对象，频繁创建销毁，JVM 的 Young GC 快被搞疯了。改成数组加游标后，GC 时间降了 70%。
楼主你问有没有翻盘余地？有。只要场景里插入删除特别频繁、而且不关心随机访问，链表依然能打。但写业务代码的人一年能遇到几次这种场景？
楼主这问题问到点子上了。其实你想反了，链表没死透，只是从"默认选择"变成了"特定场景工具"。
我第一份工作带我的老哥说过一句让我记到现在的话：数据结构没有优劣，只有合适不合适。但现代 CPU 是真不喜欢链表。
为啥？内存访问模式。数组是连续的，CPU 加载一个缓存行 64 字节，能把接下来好几个元素一起拉进来。链表呢？每个节点散落在内存各处，加载完一个还得再去内存捞下一个，缓存命中率低得离谱。你写代码觉得 O(n) 遍历没问题，但实际跑起来比数组慢 5-10 倍一点不夸张。
我自己 2024 年做过一个 LRU Cache，当时就是 HashMap + 双向链表，这是教科书标准答案。结果压测的时候发现并发一高，锁竞争把链表操作的耗时全吃掉了。后来换了 ConcurrentHashMap + 时间戳方案，性能直接翻倍。链表优雅，但现代场景压根不给它表现的机会。
不过 Redis 还在用链表，Linux 内核里也大量用，说明它没死，只是退居二线了。写业务代码的，确实很少碰得到非用链表不可的时候。
