打包时测试死循环：原子加丢更新是架构移植里最难看见的那类问题
一、“丢失更新”至少有三种长得不一样的表现
一个发行版在某架构上的移植版，编译打包时卡住：某个数学软件库的自带测试陷入死循环，直到打包超时被终止。第一次排查得到的结论只有一句：原子加指令在特定情况下会丢失更新，原因未知。
这句结论里的“丢失更新”是现象的统称，它至少包含三种要分开处理的表现。
| 可观察表现 | 需要的采集方式 | 优先怀疑的根因族 |
|---|---|---|
| 累加结果小于实际操作次数 | 在测试末尾把计数器与已提交的操作次数并列输出 | 原子性不足，读改写序列被并发打断 |
| 循环的退出条件永远不满足 | 逐轮记录读到的共享变量值与迭代序号 | 内存序造成的可见性延迟，值已写但对侧读不到 |
| 并发计数在压力回落后退到旧值 | 按时间戳连续采样同一个计数器，覆盖压力变化前后 | 指令实现与调用方语义库的预期不一致 |
三者不能互换。第一种是少算，第二种是看不见，第三种是算过又没了。区分它们的成本很低，收益是把搜索空间从“整个运行时”收缩到“其中一层”。这张表也适合直接写进缺陷登记模板，因为三种表现对应的观测手段本来就不同：第一种只比两个数，第二种要在循环里采样，第三种要在压力变化前后各留一段记录。这三种采集都不需要改被测库的源码，只在测试侧加输出。
对做交付的我们来说，这一步的价值很实在：客户环境报“计算结果不对”时，先花十分钟判断它属于哪一族，比立刻开一轮全量回归便宜得多。但要同时说清，这是排查的第一刀，不是结论。在没有可复现样例之前，任何一种表现都可能由多个原因共同造成，把它当定论写进报告，后面的人会照着去找一个不存在的东西。
二、为什么它表现为死循环而不是报错
并发退出条件依赖一个共享变量被正确更新。更新丢失时，逻辑本身仍然自洽：条件没满足，就继续下一轮，每一步都讲得通。测试里没有一条断言可以失败，因为没有任何中间状态被定义成非法。运行时的错误处理也帮不上，这里没有非法访问，没有异常，整个系统在做一件“错但完全合法”的事。
这带来两个连锁后果。一是问题的表现形态是挂起而不是失败，流水线侧看到的是一个超时，很容易被归成环境问题重跑一次；恰好重跑通过，这条记录就变成一次偶发，缺陷从此消失在构建日志里。二是这类缺陷不会在任何一层日志里自称是缺陷，日志能给出的只有一句“某个阶段耗时异常长”。
所以挂起类问题的第一处理原则不是重跑，是留现场。第五节写要留哪三件。
三、“现象确认了、原因未知”是常态，复现本身要三步
第一次排查能得出“会丢更新但原因未知”，其实已经算做得好：它证明了现象，并且诚实地把原因留在未知状态，没有硬凑一个解释。这类问题的第一手材料从来不是推理，而是复现。复现本身要三步。
- 最小化到能稳定触发的规模。把输入缩到最小组合，把并发量调到能反复出问题的档位。能稳定触发，才有资格谈观测；在“偶尔出现”的状态下做任何分析，都是在给噪声编故事。
- 剥离无关依赖。把可选后端、额外链接项与宿主环境逐项去掉，只留一条从测试到被怀疑操作的路径。能解释的变量越少，结论越站得住。
- 固定随机性。线程数、调度约束与随机种子各锁一档，形成三个可复现的配置并记录下来。不做这一步，后面任何“改了一下就好了”都无法判断是真修好了，还是这一轮碰巧没触发。
三步的目标只有一个：把“偶尔发生”改写成“每次都在同一处发生”。只有在这个前提下，任何关于原因的说明才是可检验的，也才谈得上交给别人复核。
四、跨架构差异的三个来源，与双架构基线怎么写
同一份源码换个架构跑出不同结果，差异最常见的来源有三个，而且它们不在同一层。
- 原子指令的实现强度不同。同一句抽象操作在不同架构上映射到的指令，附带的最低保证不一样：有的只保证这一步不可分，不保证它与前后的读写之间是什么关系。
- 缓存与预取的时序不同。一次写入什么时候对另一个执行单元可见，取决于这一层的实际行为，而不是源码里写下的先后。
- 内存屏障只在弱序环境里才真正起作用。在顺序本身就很强的实现上，缺屏障的写法可以一直碰巧正确。
第三条是理解整件事的钥匙。弱序架构上的测试更容易暴露问题，不是因为这一层更差，而是它把强序架构上被巧合掩盖的那层假设揭掉了。这条判断直接改写移植验收：单架构上的通过不构成正确性证据，因为它根本没测过顺序依赖这一项。
于是验证基线应该这样设：同一套测试在参考架构与目标架构各跑一遍，要求结果一致；出现不一致时，判定顺序是先问“参考架构是不是依赖了巧合”，再问“目标架构是不是有缺陷”。这个顺序不能反。反过来做，会把每个差异都当成目标架构的问题，最后要么把本来正确的实现改掉，要么在错误的那一侧打补丁。判定要留下三样证据：同一份输入的标识、两侧各自的实际结果、以及这条差异属于第一节里的哪一族。
五、回归要补的三类用例，以及日志为什么看不见
回归集要补的用例正好对应那三族，一类一类写：并发计数类，大量自增之后核对总数；依赖退出条件的循环类，把终止条件写成由共享变量驱动，并给循环设一个显式的迭代上限；原子量被多个线程交错读写的状态机类，让读它与写它在时间上互相穿插。这三类在多数项目的测试集里是缺的，原因很朴素：写起来麻烦，而且在开发机上几乎总是通过。
业务日志在这类问题上帮不上忙，原因是层次对不上：缺陷发生在指令与内存序这一层，业务日志的粒度在它上面好几层，中间没有任何机制会把这一层的事件报上来。能间接反映的只有两样——计数器的值序列，以及带时间戳的迭代记录。也就是说，检测手段要专门造，不能指望现成的观测体系顺手覆盖到。
挂起类问题的现场保留三件：栈回溯，看清卡在哪个调用序列上；线程与核的绑定状态，看清当时并发是怎么排的；失败前的迭代序号，看清是跑了很多轮才不动，还是从一开始就不动。这三样必须在终止进程之前取到，之后的任何重建都只是猜测。洹拓给客户做移植项目时，会把“保留一次挂起现场”写成流水线里的一个固定步骤，而不是指望工程师当场手快。
六、模型用在哪一步，企业侧能落的三项预防
把模型用于这类定位，真实收益集中在一处：把上千次人工试读汇编的工作，压缩成对候选模式的枚举。它能快速给出“这一类写法在缺少某种保证时可能出问题”这样的待验证组合，让搜索面迅速缩小，让人把时间花在判断而不是翻找上。它的边界同样清楚：给出的因果解释要当假设而不是答案，每一条都必须回到可复现样例上确认。模型不能替代复现，它替代的是复现之前那段最耗人的筛选；如果跳过确认直接采纳，等于把缺陷清单换成了另一份不可检验的清单。
企业侧能落的三项预防，成本都不高。
- 把“至少两个架构跑同一套并发测试”写进移植验收条款，做不到这一点的移植结论一律标注为未验证，不进入发布判定。
- 给关键的并发计数器加上界与下界的自检：超过预期上界、或低于操作次数对应的下界时主动报告，而不是等结果被下游用走之后再倒查。
- 偶发挂起的构建必须保留现场并登记，禁止“重跑通过就当作没事”；这一条要靠流程约束，不能靠个人自觉。
最后一条判断值得写在移植项目的看板上：任何“重跑一次就过了”的并发用例都还留在缺陷清单上，只是这一轮没触发。把它从“偶发环境问题”改判成“未定位缺陷”，才是这类问题能够被解决的起点。