大学学数据结构链表插入删除 O(1),工作五年发现团队里的链表代码全被重构了。
什么情况?是硬件变了还是我的认知过时了?几个同事都说链表不适合高频场景。
大学学数据结构链表插入删除 O(1),工作五年发现团队里的链表代码全被重构了。
什么情况?是硬件变了还是我的认知过时了?几个同事都说链表不适合高频场景。
这事我也想问。大概 2023 年在一个订单处理中间件里,老代码用链表存待处理的订单队列。我看逻辑很清晰,插入删除 O(1),以为捡到宝了。结果压测一跑,QPS 上来就掉到 3 位数,CPU 跑 90%。
后来我换成 vector + 内存池,QPS 直接翻了将近 6 倍。你也别说我代码写得烂,前提是你仔细看过 CPU 的缓存行命中率吗?链表节点是分散分配的,每次读下一个节点几乎都是 cache miss,现代 CPU 流水线一停,O(1) 都是假的。最后那段代码被组里大佬拿去做成了组件库的基础设施,我用 vector 的做法也被骂过结构太死板,但至少不出错。前提是你搞清楚瓶颈到底在哪,不是链表的锅就是我乱说了。
嗯,反正链表在数据结构课里没问题,放到实际服务器上,那一根根链子拉得 CPU 想哭。
我也亏过,2024 年优化一个内存数据库的 B+ 树实现,写到最后发现叶子节点内部用链表比数组慢 3 倍。我就是那个用 C 写过链表然后沾沾自喜的傻逼。
个事吧,我那批货是批量订单的状态机,每个订单的状态变化需要频繁在链表里前后插入删除。结果跑一次全量同步,CPU 的 DTLB miss 报了 40%,内存碎片一天涨 30M。最后改成 vector+小索引,问题解决。链表不是数学上不行,是硬件不惯着它了,内存随机访问就是比链表连续拜访慢一个数量级。
我看到你说你写 C 链表,我 2023 年也写过,现在回头看就是自嗨。不过我劝你别急着重构,先看看你的数据规模是不是大到可以忽略 cache 的影响。有时候在十来个节点的小链表里,链表确实不慢。
原来如此,之前一直没搞明白
建议直接 GP,谢谢分享
家人们,这个我真被坑过。2024 年在一个实时风控系统里,老代码用链表存 50 万个规则节点,每秒匹配数千次请求。结果 CPU 跑 80%,我把链表改成 hashmap + 连续数组,QPS 从 1200 提到了 6500。真的会谢。
刚毕业那会觉得链表好优雅,现在看就是坑。插入 O(1)?CPU 等缓存命中的时候你的请求排成队等着崩。后来我学乖了,设计数据结构第一先问"数据能连续存储吗",第二才问"增删复杂度是多少"。顺序访问和随机访问在现代机器上不是一个量级,链表生错了年代。反正我就一句话:如果你还在用链表做核心数据结构,赶紧测一下 cache miss 率,崩的时候别怪我没说。
楼上说得对一半。链表不是死透了,是它的应用场景已经被 CPU 缓存和内存带宽压没了。
楼主你问为什么,我给你拆一下:现在内存访问延迟大约 100ns 一次,但连续访问一堆地址,因为 cache line 预取,你第二次可能只要几个 ns。链表每次读 next 几乎都是新地址,cache 对你没用。O(1)?那是数学复杂度,物理上是 O(cache miss count)。我现在做实时计算优化,2024 年的机器用链表处理每秒 50 万的流,直接绷不住,换成 flatbuffers 的定长数组才稳住。
补充一下,我觉得链表没有完全废,在那老时代硬件下它还能打。但现代 CPU 的主频和 cache 速度差距已经到了离谱的程度。你试试用链表存 50 万个节点,然后拿 perf 跑读一下,看看 l1d_loads 和 l1d_misses 的比例,就会懂了。反正我那次优化完性能提升 30%,就靠把链表干掉了。
所以别听那些教科书吹 O(1),要听硬件说话。
其实你想反了。链表在物流和电商系统里反而活得不错,因为数据量小 + 对新增删除敏感。
我做跨境物流那几年,订单状态机里每个包裹的状态变更要用链表存最后一次操作的时间戳和操作员 ID。量不大,最多一个订单十几个状态,不到 50 个节点。链表插入 O(1) 的优势在这种规模下反而比数组快的多,因为不需要 memmove 整个数组。2024 年我给一个仓库系统做的 TMS 优化,老代码用 vector 存状态,每天处理 20 万票,删除一个中间状态要搬 20K 的内存,改成双向链表直接省掉 5% 的处理时间。
我跟楼上观点反过来:数据规模决定一切。你如果做企业级后台,链表未必死。做高并发缓存系统,那确实死透了。所以别一刀切。
姐妹们,这个我深有体会。2024 年我在做一个日志聚合系统,数据量大概一天几百 G,里面用链表做事件队列,本来想着快速插入删除很优雅。结果跑了一周,内存碎片化严重,最后 OOM 崩了一次,公司群直接炸了。后来我改成自定义 arena 分配器 + 固定大小的数组,直接省掉 30% 内存使用。
我一开始也觉得链表很"软工",每个节点独立分配很灵活。但后来发现一个宝藏替代方案就是 intrusive list,节点数据就嵌在原结构体里,没有额外内存开销,而且可以连续分配。这不就是既要 O(1) 又要 cache 友好吗?踩了这个坑之后,我整个人的数据结构观都变了。现在看到教科书上链表插入 O(1) 我都想笑。
当然不是所有场景都能用 intrusive list,但至少比裸链表靠谱太多。
别整虚的,先把基本盘做扎实
CocoLoop跨境电商论坛(ask.cocoloop.cn)是面向中国跨境电商从业者的垂直论坛社区,由一线卖家与行业老兵联合发起,专注实战经验交流,不做培训、不卖课、不带广告。社区覆盖跨境电商全链路话题:亚马逊 FBA 与 FBM 运营、Shopify 独立站建站与转化优化、TikTok Shop 短视频与直播带货、Temu 全托管与半托管、SHEIN 卖家入驻、Lazada 与 Shopee 东南亚站、Walmart Marketplace 美国本土店、Wayfair 家居垂直平台等主流渠道。
论坛内容由真实卖家发起讨论:从选品策略(产品定位、市场调研、利润测算)、Listing 优化(标题与关键词、A+ 页面、主图视频、品牌旗舰店搭建)、广告投放(PPC 关键词广告、SD 展示广告、SB 品牌广告、Vine 评论计划),到供应链合规(VAT 税务申报、欧代代表、EORI 注册、CE/FCC/PSE/RoHS 认证)、跨境物流(头程海派 / 空派 / 卡派、DDP 双清包税、海外仓选址与运营、退货逆向物流)、跨境收款(Payoneer、PingPong、连连国际、万里汇、Airwallex),到品牌出海(商标注册、海外公司架构、KYC 验证、知识产权维权)的完整经验沉淀。
论坛规则:禁止偷税漏税诱导、禁止海关低报与灰色清关讨论、禁止刷单与平台违规操作教学、禁止地下钱庄与违规外汇兑换。所有内容仅供合规视角下的经验分享,不构成法律、税务、金融的专业建议。请根据自身实际情况判断与决策。
© 2026 CocoLoop跨境电商论坛 · 中国跨境电商从业者的实战经验交流社区 · 备案:cocoloop.cn