都说链表缓存不友好性能差，那现代高并发系统里链表到底还有没有用？

去年我们有个服务被 OOM 搞了好几次，查来查去发现是一张全局表用了 ConcurrentHashMap 的链表升级红黑树那个逻辑。大量 key 哈希冲突到一块，链表长度超过阈值，触发了树化，树化过程又锁了整段桶，直接把吞吐干到零。
后来怎么解决的？换了个更好的哈希函数，让数据散开，树化根本不会触发。你说链表已死？它死之前先把你服务的性能搞死了。这玩意就跟地雷一样，你踩到了才知道疼。

我去年调一个消息队列的消费逻辑，就是把待确认的消息串成一个链表挂在内存里。当时也琢磨过要不要换数组，结果一算，消费端是随机确认的，数组中间删一个元素后面全得挪，那个拷贝开销直接爆炸。链表删节点就是改两个指针的事。
但你要说链表快，那也得分场景。纯遍历确实被数组吊打，缓存预取那一块就差了好几倍。我这块逻辑主要靠跳表兜底，链表只是辅助。
反正我现在写代码的原则就是，LRU、LFU 这种带淘汰策略的，链表该用还得用，别听风就是雨。

其实你想反了，现代社会不是链表死了，是"链表思维"活了。
你看现在各种无锁队列，什么 MPSC、SPSC，底层全是链表。为什么？因为 CAS 操作能原子地改指针，你拿数组去 CAS 一个中间位置试试，ABA 问题直接搞死你。
前几天我写了个日志收集器，消费者就一个线程，生产者好几个，我就用了无锁链表，一个 CAS 搞定入队，稳得一批。你说它缓存不友好？那点开销和锁竞争比起来，算个屁。老哥你业务里真遇到性能瓶颈，先看看锁，别老盯着链表。

楼上说得对一半，链表确实是个坑，但它那个坑主要在哈希冲突极端场景。我平时写业务，List 都用切片，但 Redis 那个 quicklist 你们知道吧，它就是链表和压缩列表的合体。短的时候用压缩数组省内存，长了就拆成多个节点串链表，这设计就很鸡贼。
所以我觉得，链表的死期还没到，它只是退居幕后了。你用不着它，但你用的框架底层全是它。就像水电煤，你感受不到，但没它真不行。

我懂你这种困惑，刚转后台那会儿我也觉得链表是上个世纪的古董。但后来做网关的限流组件，用了一个叫时间轮的玩意，底层就是环形链表加桶。每个请求过来，往当前时间对应的桶里塞节点，到点了整桶清掉。这个结构用数组做，你得处理环形数组的边界，还得考虑扩容，链表的灵活性一下就体现出来了。
当然，现在 C++ 那边喜欢用 instrusive 版本，性能更好。反正别一棍子打死，该用还得用。

你举的源码例子，大概率是 Java 的 LinkedList 被骂，以及 Linux 内核里那个 list_head 被吹上天。这两者完全是两个物种。
LinkedList 是给业务仔用的，你存个对象图、做个栈、当队列，没问题，但你要是拿它去遍历，那确实脑子有坑。内核那个 list_head 是侵入式的，节点嵌在结构体里，不额外分配内存，配合 container_of 宏，操作起来开销极低。
所以"链表已死"这事，你得看是哪层。用户态业务代码里，它确实半死不活；内核态、基础组件里，它活得好好的。前提是你得知道它为什么活。