为什么很多老码农说链表在现代体系里"已死"？我写个高并发模块还在用链表，真不行？

其实你想反了。链表在现代体系里不是"已死"，是"转型了"。像Linux内核里全是intrusive list，C++里boost.intrusive，还有Redis的quicklist，它们都不是你写的那个new/delete式的链表。因为现代硬件瓶颈在内存延迟，不在计算。你写个普通链表，每次新节点都是堆分配，CPU得等内存分配器给你找空闲块，慢得要死。而且链表没法预取，CPU分支预测碰到链表指针跳跃基本废了。真要用链表，搞预分配内存池+数组索引，或者用spalloc那种无锁分配器，不然不如别用。

讲个真题案例。2025年我帮一个做跨境电商ERP的朋友优化订单合并模块，他原来用双向链表做待合并队列，处理100万条订单花了3秒。我换成数组+二分查找，优化到0.8秒。原因很简单：链表虽然插入快，但你要做合并操作得全表遍历找重复的订单号，每次都得从头开始。数组排序后二分查找，再配合跳表或者hashmap做索引，直接就秒了。链表真不是"死了"，是"用错了地方"，你该用数组的地方用了链表，那只能怪自己。

楼上说得对一半，但我补充一个点：链表在跨语言场景下反而有用。比如你跨境电商后台Python做调度，C++写协议层，那C++里用链表做任务队列，因为分配可以规整、不需要扩容，而且操作锁粒度小。但你要在纯Go或Java里用链表，那确实不如slice/arraylist，因为那些语言的内存分配更碎片化。所以"死了"是相对的，看语言、看场景。我2023年给一个物流模块重写，Go里用ring buffer，Python里用deque（双向链表实现），都跑得挺好。

楼主这问题让我绷不住了。链表死没死我不知道，但我知道你组里新来的架构师肯定比你懂。我做跨境后台三年了，见过太多"链表党"被优化掉。你试想一下：一个订单模块处理1000个订单，链表遍历每次都得走指针，CPU得等内存拉数据，等个几十个纳秒就卡了。数组是连续内存，一次预加载能读完几个cache line。不信你自己写个benchmark，10万次插入+遍历，数组比链表快5-10倍。什么O(1)插入？那只是理论，实际IO开销大得离谱。

我也亏过。当年帮一个客户做跨境电商物流追踪系统，核心队列用链表，测的时候好好的，一上线大促就崩。后来换成环形数组+CAS锁，吞吐量翻了3倍。说链表"死了"有点极端，但你写高并发模块还纯靠链表，那真是在给自己挖坑。除非你用 intrusive list，不然节点分配和释放太频繁了，堆压力大、缓存差。反正我现在写新项目，链表只用来做LRU cache，别的地方能用数组打死不用链表。

我懂你这种慌，当年我也觉得自己链表写得牛，结果被部门老大一句话点破："链表是纸面上的O(1)，实际是CPU级的O(n)"。我做跨境电商合规和系统架构的，现代CPU的缓存在链表面前就是个摆设。而且现在很多高并发框架像Disruptor，用的都是环形数组，连锁都不用了。你要想继续用链表，至少得用内存池做预分配、减少分配开销，不然每次new节点都是堆分配，用久了内存碎片一堆，GC都受不了。

朋友们，这事我说句大实话：链表在面试题里确实没死，在课本上也没死，但在你写的高并发后台里，它真的快被淘汰了。我做跨境电商后台五年，最后悔的就是第一年死磕链表。后来看了CPU架构的书才明白，现代处理器是"预取+流水线"的，数组因为连续，CPU能提前把后面几条数据拉进缓存，链表一指针跳一下就得等内存。真的会谢。不过你要是写嵌入式或者实时系统，那链表还是yyds，因为分配可控。一句话：场景决定生死，别盲信"O(1)"的谎言。

你这个数据靠谱吗？我怀疑你那个架构师没跟你说全。链表在极低并发下确实还行，像你那种每秒几百笔订单的模块，用链表也没问题。但如果你做到秒杀那种几千QPS，链表就扛不住了，因为每次查节点都得从头遍历，而且现代CPU的缓存预取机制一碰上链表就废了，缓存miss率飙升。你要是真关心性能，去调一下perf看L1缓存miss率，链表能比数组高3-4倍。不是"死了"，是"没效率"。