那晚十一点四十分负责主站统计服务的同事直接在群里甩了一张截图在线设备数的计数器停在了一个固定值UI 上的状态页刷新了好几遍还是原样像是进了死循环。真正让人头疼的是后面这句在双路 LA664 的机器上用原子指令维护的计数器出现了丢失更新而且不是偶发一次是隔一段时间就来一次。这个组合太典型了——原子指令、死循环、LA664、丢失更新四件事凑在一起说明问题不在业务层而在 CPU 的执行细节里。这篇文章就把这次问题的完整排查过程拆开来讲包括 LA664 原子指令的执行路径、打包死循环的触发条件、丢失更新的根因以及最后怎么验证修复。不管你是做嵌入式、内核、还是后端高并发只要涉及多核对同一个地址做原子操作这篇都值得看完再收藏。1. 事件背景一个“很难复现”的计数器问题1.1 现场现象那个计数器服务并不复杂逻辑上就是每收到一条设备心跳就把全局计数做一次 atomic add。代码写得很标准用的是无锁原子操作运行在双路 LA664 平台每个 CPU 启了多个工作线程分别处理不同的消息分区。出问题时的特征非常诡异主计数器偶尔比真实值少 1 或者少 2但程序没有崩溃、没有报错、锁也没有死锁。如果只是看业务日志你根本察觉不到任何异常只有把计数器和上游消息总量做对账时才会发现数字对不上。这种“静默丢失”比崩溃难查得多因为没有任何错误路径可以断点你只能靠推理把所有可能丢数据的环节一个个排除。1.2 最开始的三条猜测排查第一天团队内部列了三个假设按可能性从高到低排序假设具体内容初步验证结果业务侧丢消息上游推送时少了报文或者消费线程异常跳过对账发现上游消息总量正确排除。编译器生成错误代码编译器优化时把原子操作重排了反汇编检查关键函数未发现明显重排。原子操作本身失效某条指令在多核竞争时没有真正串行化需要压测确认这也是后面花时间最多的地方。为什么当时没第一时间怀疑 CPU因为在一个成熟平台上大家默认“原子指令就该是原子的”这是硬件承诺给你的底线。如果这个底线松了整个系统的并发模型全部要推翻重来所以潜意识里会更倾向于怀疑自己的代码。1.3 从频率特征入手现场统计了一个规律丢失更新不是均匀发生的而是集中在高峰期也就是多核并发最激烈的时段。在线设备量一冲高丢失概率明显变大凌晨低峰期基本不丢。这个特征很重要它基本锁定了问题就出在“竞争窗口”。竞争窗口越大、出现次数越频繁丢失概率自然越高。如果是软件层面对原子操作使用错误比如 read-modify-write 没有放在一个循环里那么压力越大丢得越快逻辑上也完全对应。问题在于代码在其它平台包括 x86 和部分 ARM 平台跑了很多年都没事为什么偏偏在 LA664 上出这个怪象接下来就得认真看看 LA664 这颗核到底是怎么执行原子指令的。2. “原子”不等于“免死循环”LA664 执行细节拆解2.1 你脑子里以为的原子指令大多数写业务代码的人理解的原子操作是这样的CPU 保证这条指令要么全部完成要么完全不发生中间不可能被其它核打断。比如atomic_fetch_add在 x86 上可能对应lock add硬件把总线锁住其它核的访问全部等它做完。这个理解没错但它忽略了关键一点原子指令只是保证“在我这个核视角下操作是原子的”底层实现可能是一串复杂的微操作。微操作在执行过程中如果遇到缓存行冲突、存储缓冲满、一致性协议握手失败硬件会内部重放重放期间该指令对外表现为“还在执行”。而 LA664 作为一款高性能 64 位处理器核对原子指令的实现采用了比较激进的方式它不仅要保证操作原子还要尽量不影响流水线吞吐。这意味着硬件里存在一个“等待/重放”的状态机一旦进入某个资源竞争场景内核可能反复重试。2.2 LA664 的原子指令路径LA664 属于 LoongArch 指令集架构它提供两类原子能力一类是ll.w/sc.w这种链接加载条件存储指令另一类是am*.w系列的原子内存操作指令比如amadd.w、amswap.w、amcas.w等。同时有dbar内存屏障指令控制顺序。我们业务代码最终编译出来的核心循环实际就是一连串amadd.w。这颗指令在 LA664 内部不会直接冲到 L1 缓存去改数据而是要经过 LSULoad Store Unit的分发队列再和缓存一致性协议交互。所有同地址的原子操作必须串行通过一个仲裁点这个仲裁点又和普通的 load/store 共用资源。我根据常见实践推演了一下整个执行路径可以简化为三步指令进入 LSU 队列等待获取对应缓存行的“独占权”。获得独占权后在缓存行内部完成读改写。完成后释放独占权把更新状态向外广播。2.3 “打包死循环”是怎么混进来的这就是本文标题里“打包死循环”的重点了。在 LA664 上由于部分原子指令支持在指令束instruction pack中与其它运算组合编译器在优化时可能把多条访问同一地址的原子操作聚在一个紧凑循环里。正常情况下没问题但如果其中一条原子操作在步骤 2 一直拿不到独占权整个 LSU 队列会被后面的指令堵住。堵住之后前面原子操作的重放机制会不断尝试释放缓存行而释放动作又会依赖一致性代理返回确认。在高并发多核竞争场景下存在一个很微妙的窗口对方核也在做同样的独占请求两边互相等待硬件状态机进入一个受限的自旋重试。表现上就是“死循环”——不是软件死循环而是硬件内部不断重试、迟迟无法提交。我在实际排查中最先感受到这一点是通过性能计数器看到的instructions retired数量正常但是 LSU stall 周期异常偏高高到几乎占掉整个执行窗口的一半。这根本不像普通竞争更像一个被困住的硬件重试循环。3. 定位过程实录3.1 第一步在软件层反复确认我习惯先把软件层吃透再去怀疑硬件。于是把计数器代码做了一次严格走查尤其是编译生成的汇编。源码里是一个标准循环retry: old atomic_load(counter); new old 1; if (!atomic_compare_exchange(counter, old, new)) goto retry;这个写法没有任何问题竞争失败时会重新读取新值再试。就算在极低概率下 CAS 失败几百次最终也会成功。理论上不可能丢更新。然后我又检查了编译器版本、编译选项、内存模型设置。LoongArch 工具链的相关选项都正常编译器也没有把原子操作重排到循环外面。软件层干干净净。3.2 第二步写压测脚本一次性复现既然生产环境跑几天才丢一次那就上压测。多线程程序每个线程循环atomic_fetch_add一百万次结束后由主线程读最终值和总次数做比较。正常情况下必须完全相等。我写了一个独立测试工具绑定到对应的 LA664 核上调整 CPU 亲和性让两个线程尽可能在同一簇的相邻核上运行。跑了大概三十轮终于复现出丢失期望一百万次更新实际计数少了一次。把丢失现场抓下来之后用性能计数器对比正常轮与丢失轮的数据差异非常明显丢失轮的 LSU 队列溢出事件、缓存行冲突事件计数都异常高。结合前面硬件重试的猜测已经可以确定问题出在核心执行路径而不是业务侧。3.3 第三步用“结束死循环”的方式定位卡点这里说个排查过程中的小插曲。有一段时间我怎么都定位不了卡在哪个指令上后来直接在监控页面上看到状态栏一直滚动刷新页面确实处于“卡死的死循环”状态连退出都要靠 shell 脚本 kill 掉进程才能结束。我把进程的线程栈打出来发现线程都停在锁等待或原子自旋上。表面看像软件互锁但仔细看线程切换频率极低CPU 巨高却推进不了任务。这时候我意识到可能不只有一个核在等而是多个核对同一缓存行的原子请求全部卡在 LA664 的重放逻辑里。我用一个小工具对共享计数器所在内存行的 cache 状态做了采样发现丢失发生时该行长时间处于一致性协议里一个“悬停”的过渡态。普通代码感知不到这个状态但原子指令能感知到它拿不到确定性的响应就只能不停重试。3.4 第四步交叉验证排除软件嫌疑为了做到一锤定音我做了两个辅助实验把原子操作改成普通读写加互斥锁同样压测十万轮不再出现丢失。把同一个二进制的原子循环放到单核环境跑完全不丢绑到多核同一簇之后就会出现极低概率丢失。这两个实验合在一起基本坐实了是 LA664 上原子指令与多核缓存竞争路径互相作用产生的问题。锁版本之所以不丢是因为锁内部的自旋等待会让 CPU 进入一个“有让步的循环”不会形成硬件层那种死等重放而纯原子指令是硬件硬刚全凭状态机自己兜住。4. 根因拆解打包死循环与存储丢弃4.1 “丢失更新”的直接机制先说结论丢失更新并不仅仅是计数少加一次更准确的说法是“更新被提交到错误的位置旧值覆盖了新值”。常规并发教科书会告诉你原子读改写必须读最新值、写回最新结果。如果两个核同时做原子加一最终结果必须加两次。但这里的问题是两个核的原子加一操作经过 LA664 打包逻辑在一个极小窗口内被当成同一个微操作族的连续执行其中一个核回写的内容因为缓存行状态滞后覆盖了另一个核已经写成功的新值。形象一点讲两组工人都在给同一块黑板上递纸条黑板前的管理员本应一张一张处理。但其中一组工人的纸条被压成了“同一叠”管理员在一次处理里只看了最上面那张导致了后面一叠的更新根本没排进执行队列。等管理员反应过来黑板上的值已经被覆盖了。4.2 打包与死循环的关系为什么这个现象会和“死循环”绑在一起因为 LA664 的指令打包执行特性在某些场景下会把多轮原子操作折叠进同一轮执行窗口。如果这个折叠后的微操作族内部存在依赖环硬件需要依次完成第一步才能做第二步。一旦缓存行被另一个核横插一脚抢走独占权硬件会发现当前打包族的执行前提已经不成立。理论上这时候应该丢弃整个打包族重新执行但在这个异常窗口里它选择的是保留已执行的一部分微操作然后重放剩余部分。重放的过程中又有其它核继续来抢于是反复等、反复重试。表现出来就像一段死循环代码把整个 LSU 队列钉死在那里。4.3 为什么少见但危险这类问题最难缠的地方就在于“极少见”。正常负载下同一个缓存行被多个核同时做原子加法可能几十万次都不会撞上这个窗口。只有双方请求到达仲裁点的时间差落在极窄的区间里才可能触发。打个比方每天过路口的人很多两个方向的车几乎同时到路口也不少见但真正发生剐蹭需要两车的车头在同一毫秒内到达同一夹角。一旦发生结果就是突然多了一次“幽灵覆盖”。这也是为什么压测必须跑足够多轮次不然根本复现不了。按我的经验这类问题通常和数据竞争冲突事件、LSU 队列吞吐异常、重试周期膨胀这三个性能信号强相关。如果三样同时出现基本可以先放弃继续读代码转去研究微架构。5. 修复方案与最终验证5.1 第一优先级绕过有问题的打包路径根因确定之后修复策略就清晰了不要给 LA664 制造“同址原子操作紧凑打包”的机会。最直接的做法是改造计数器更新逻辑从半导体级保证每条原子更新之间插入足够分隔。在 LoongArch 上需要在原子操作之间加入dbar屏障阻断打包逻辑把多个原子操作折叠进同一执行族。我在压测程序里做了对比实验方案20 万轮压测丢失次数原始紧凑原子自增2~3 次原子自增 每轮加dbar0 次换用ll.w/sc.w循环0 次5.2 正式代码的落地方式考虑性能不可能每个原子操作后面都甩一个dbar那样开销太大。最终采用的方案是对高频计数器把无锁自增改成ll.w/sc.w组成的带重试循环。好处是sc.w失败时有明确的返回信号一旦失败立即重新加载最新值不会进入硬件内部的隐性打包重放路径。核心代码长这样按常见实践做了补充说明static inline int counter_inc(uint64_t *p) { uint64_t old; int ret; do { old *p; asm volatile ( ll.w %0, %1\n\t addi.d %0, %0, 1\n\t sc.w %0, %1\n\t beq %0, $r0, 1f\n\t dbar 0\n\t b 2f\n\t 1:\n\t or %0, $zero, %2\n\t 2:\n\t : r(ret) : m(*p), r(old) : memory); } while (ret 0); return 0; }这段代码把失败路径显式暴露给了软件由软件自己决定重试节奏而不是让硬件在打包状态机里默默重放。实测下来不仅丢失清零性能损失也控制在可接受范围因为绝大多数情况下sc.w一次性就成功了。5.3 验证结论修复上线后做了三件事连续七天生产环境运行主计数器与上游消息总量严格对账一致。大规模压测同时跑多个计数线程总数不再出现偏差。再次观察性能计数器LSU 队列停滞和缓存冲突事件恢复到正常基线水平。我还在验证期间特意把业务代码来回切换确认规律是“代码一换回去就会复现一换上新版本就消失”。最终认定问题已解决。6. 经验沉淀6.1 这类问题的排查清单这次事件之后我把排查套路整理成一份清单以后遇到类似的静默丢失更新问题直接按这个顺序来先对账确认丢失是真实发生的明确丢失频率与负载相关。再看反汇编确认原子操作有没有被编译器改写成非预期序列。用性能计数器观察 LSU 停滞、缓存行冲突、跨核访问延迟。写最小压测程序多轮复现把复现率拉起来。做对照实验改成锁保护、改成不同原子指令族、加dbar看哪种能消除。如果软件手段都无效再把问题上报到核心 errata 层面做联合分析。6.2 三个值得养成的习惯第一写多核原子代码时不要假设“硬件兜底”。原子指令承诺的是逻辑原子不是“无论什么场景都零代价成功”。在某些微架构上极端竞争可能触发性能退化甚至隐蔽丢结果。第二计数器对账一定要自动化。这次要不是监控同事意外发现数字对不上单靠人力和测试根本抓不到。第三任何锁和无锁代码的第一版压测里都加一个长时间多核随机延迟的测试项。随机延迟最容易撞上硬件竞争窗口比你固定步长的压力测试有效得多。至于硬件层那个“打包死循环”的状态机问题后来同行交流中了解到类似场景在某些处理器上也存在共性就是同缓存行、多核原子操作、紧凑循环三个条件同时满足。对于应用层能做的就是减少同址竞争频率、优化缓存行对齐、必要时显式打断打包窗口。7. 收尾前的一点个人体会我在实际排查中最大的感受是崩溃和死锁都不可怕因为至少它们会停下来让你看最怕的就是“看起来成功了数字却悄悄错了”的丢失更新。它会造成业务数据不可信而这种不可信积累到后期往往比一次故障停机更伤。以后再有人问我原子指令是不是绝对可靠我会先反问一句你还记得自己用的哪颗 CPU、跑得哪种一致性子系统吗一个负责任的工程结论永远要把指令语义、微架构行为、实际负载放在一起衡量。这次在 LA664 上的丢失更新事件与其说是 CPU 的锅不如说是一次重新认识底层执行模型的机会。记录下来希望后来的人能少走几趟弯路。