为什么现在都说链表在现代计算机里没用了？性能真有那么差吗

我懂你这个困惑，我当初也纠结过这个。工作第三年接手一个数据处理模块，慢得离谱，一批数据要跑十几秒。我一看代码，核心结构用的链表，心想插入删除都 O(1)，怎么会慢。折腾两天优化别的逻辑，缓存也加了，批处理也做了，性能提升百分之十五。就十五。
后来组里大佬点了一句：你碰一下链表节点试试。我拿 perf 一看，cache miss 吓死人，内存访问跟散步似的，一个节点一个地址，CPU 预取器直接废掉。换成一个连续数组，重写加删除逻辑用标记位，性能直接翻三倍。
所以说"链表已死"有点夸张，但在大多数业务场景下，它确实是被 CPU 缓存按在地上摩擦的那个。真的会谢。

姐妹你这个话题我太有同感了。前两天翻我们系统重构的代码评审，新来的同事写了一版用 ArrayList 替代 LinkedList 的方案，评论里吵了二十多层楼。
我自己的经验是，链表最尴尬的地方在于：你理论分析觉得 O(1) 很香，但实际跑起来，每一次 next 都是一次指路牌查询，内存地址跳来跳去，CPU 都得跟着蹦迪。而数组是连续地板，预取器哗啦一下就全搬进缓存了。
踩雷的是，我见过有人为了省删除元素的拷贝开销硬上链表，结果批量操作时 GC 压力巨大，节点对象满天飞。宝藏方案反而是用数组加一个"逻辑删除"标记，遍历时跳过就行，内存友好还好调试。
不过话真到了无锁并发或者内核链表那种级别，那就是另一套玩法了，咱应用层确实碰得少。

补充一下楼上的，我在嵌入式这边做，算是供应链最底层的视角。链表这玩意儿，我们平时写驱动和协议栈，还是得用，但你问它死没死，我觉得某种程度上是"退居二线"了。
当年我做一个网络报文解析，从 A 到 B 转发，链路管理全部是 list_head 双向链表。后来芯片升级了，Cache 变大变快，但报文一多，遍历链表找空闲描述符还是明显卡顿。改成数组池加 bitmap 索引，同样的转发量，CPU 占用从百分之六十掉到二十多。
所以你说死没死？在需要动态分配、无法预知数量、插入删除特别频繁的场景，它还是那个最稳的。但在性能敏感的路径上，你会想尽办法把它换成数组或者内存池。我也亏过这个，当年不信邪，非要用链表秀操作，结果被客户现场抓包延迟过高，脸都丢光了。现在学乖了，先看数据特征再选结构。

其实你想反了，链表没死，死的是"无脑用链表"的人。
老哥，你想想 Redis 的 quicklist，一边是 ziplist 压缩数组，一边是链表节点，人家混着用，就是为了躲开纯链表的 cache 劣势，又保留插入删除的便利。这玩意儿不是非黑即白，是看你数据多大、访问模式啥样。
真要说"死"，那是教科书里那种傻乎乎的纯链表，拿来当日常容器用，确实该进博物馆了。但你要是跟搞操作系统、搞文件系统那帮人聊，链表在结构管理里面还是活得好好的，只是藏得更深了，你感知不到而已。
所以别纠结它死没死，你就想想你的数据是读多写少还是写多读少，是固定大小还是疯狂变长，适合就上数组，不适合再考虑链表。就这么简单，6。