为什么ARM上多线程程序会乱序？C++内存序深度解析

有个现象挺有意思：同一个多线程程序，代码在 x86 上连续跑一整晚都正常，换到 ARM 开发板上运行几分钟就出现诡异结果，数据偶尔丢、顺序偶尔跳。大多数人的第一反应是“是不是板子不稳定”，或者“是不是编译器优化开高了”。其实很可能问题出在 C++ 的内存序没有设计对。

我接触 C++11 的内存序，最早也是从面试题里看到的：std::atomic 有几种 memory_order，分别有什么用。当时感觉这话题很抽象，后来在实际项目里排查过一个“不是必现”的并发 bug，才真正理解到：内存序描述的不是“原子不原子”，而是“一个线程的写，另一个线程在什么条件下、以什么顺序能看到”。如果你正在学 C++ 多线程，或者工作中写无锁队列、自旋锁、共享状态标志，那这篇内容应该能帮你少走不少弯路。

1. 先理清一个问题：原子操作不等于“天然有序”

程序里涉及多线程时，真正让新手困惑的往往不是“操作会不会被打断”，而是“另一个线程看到的顺序为什么会和大家直觉里的顺序不一样”。

1.1 三件会被打乱的事

先看一段简单到不行的代码：

cpp复制int data = 0;
std::atomic<bool> ready{false};

void producer() {
    data = 42;                                   // 写数据
    ready.store(true);                           // 标记数据已就绪
}

void consumer() {
    while (!ready.load()) {}                     // 等标记
    assert(data == 42);                          // 读数据
}

如果只看代码逻辑，你一定会觉得：producer 先写 data，再置 ready=true；consumer 看到 ready=true 时，data 必然已经是 42。这句话在“单线程的世界”里没有任何问题，但在多核、多线程系统里，至少有三层因素会把假设打破：

• 编译器在优化时，可能把 data = 42 和 ready.store(true) 的顺序对调。只要它认为单线程可观察行为不变，它就可能让一条普通 store 晚一点执行或早一点执行。编译器默认以“单线程视角”优化代码，它不会为你脑补出另一个线程正在盯着这些变量。
• CPU 本身存在指令乱序执行机制。现代处理器为了填满流水线，允许后发指令先完成，只要最终结果符合架构语义。这个“架构语义”在单核上没问题，但在多核场景下，乱序窗口可能被另一个核观察到。
• 缓存也不是实时的。每个核都有自己的缓存，一个核改了 data，另一个核的缓存里可能还是旧值。缓存一致性协议能保证最终一致，但不能保证“你读的时候恰好是最新值”。

所以“先写数据，再写标志”这个顺序，在机器层面并不像源码里那么牢固。

1.2 只有一个“原子读”解决不了什么

很多人的第一反应是“那把 data 也改成 atomic 不就行了”。这确实能解决 data 本身被撕裂读写的问题，也就是原子性，但解决不了顺序和可见性问题。

std::atomic<int> 默认自带的是顺序一致性内存序，这在绝大多数场景下会让上面的代码工作得很好。但假设你图性能，写了类似这样：

cpp复制std::atomic<int> data{0};
std::atomic<bool> ready{false};

// producer
data.store(42, std::memory_order_relaxed);
ready.store(true, std::memory_order_relaxed);

// consumer
while (!ready.load(std::memory_order_relaxed)) {}
int value = data.load(std::memory_order_relaxed);

这里两个变量都不会被“撕开”，代码也绝不会因为 data 的读写一半一半而崩溃。但 data.store 和 ready.store 之间没有任何顺序承诺，data.load 和 ready.load 之间也没有任何顺序承诺。也就是说，consumer 完全可能先看到 ready == true，随后读 data 时却还没看到 42。这在 x86 上不容易出现，因为在 x86 强内存序模型下 store 不会随便乱到另一个 store 后面，但理论层面它已经属于未定义行为：data 在 producer 写入和 consumer 读取之间没有同步关系，形成了数据竞争。

结论：atomic 只是提供了“原子读改写”，内存序才是用来描述“不同 atomic 操作之间怎么建立同步关系”的规则。std::memory_order 是配合原子操作使用的，但它管的不是不要撕裂，而是顺序与可见性。

2. 六档内存序到底挡了什么：从 relaxed 到 seq_cst

头文件里定义了六种 memory_order，很多人背过名字，却不知道它们到底约束了哪条边。

2.1 relaxed：唯一不建立同步的档位

memory_order_relaxed 是所有档位里约束最少的，它只保证：

1. 对同一个原子变量的单个操作本身是原子的；
2. 同一个线程对同一个原子变量的修改顺序，不会被随意颠倒；但不同线程之间不保证任何可见顺序。

relaxed 适合什么场景？最典型的是计数器。比如一个统计次数的变量，我们只关心最终加了多少次，不关心它在哪个瞬间被另一个线程看到，也不需要一个计数器的结果去“解锁”另一块数据。

cpp复制std::atomic<long> total{0};

void worker() {
    for (int i = 0; i < 1000; ++i) {
        total.fetch_add(1, std::memory_order_relaxed);
    }
}

这里即便每个线程加的顺序不同，最终 total 只要线程完整跑完，和就是正确的。relaxed 的性能在部分弱内存序架构上会优于默认的 seq_cst，因为编译器可以做更多优化，CPU 也不必为了同步付出额外代价。但注意：这个档位的名字很迷惑人，它叫“松”，不是“没有语义”，而是“不提供顺序语义”。

2.2 acquire/release：只在碰头点生效

memory_order_acquire 和 memory_order_release 通常成对出现。

• 一个线程执行一个带 release 语义的写操作，相当于对外宣告：“我之前的写操作，都允许被观察到了。”
• 另一个线程执行一个带 acquire 语义的读操作，并且真的读到了这次 release 写下的值，那么它随后发生的读写操作都必须在这个读到动作之后。

如果换成生活语言，可以把 release 理解成“发出一个信号”，acquire 理解成“接住一个信号”。两个线程之间必须有这种“信号接住”的过程，同步关系才算建立。

以最简单的一发一收场景为例：

cpp复制std::atomic<bool> flag{false};
int secret = 0;

void writer() {
    secret = 42;                                  // 普通写
    flag.store(true, std::memory_order_release);  // release 写
}

void reader() {
    while (!flag.load(std::memory_order_acquire)) {
        // 等待，一旦读到 true，就和 writer 的 release 同步了
    }
    assert(secret == 42);  // 安全
}

这里 secret 甚至不需要是 atomic。因为 release/acquire 在 flag 上建立了 happens-before 关系，writer 在 release 之前写 secret 的动作，对 reader 在 acquire 之后读 secret 的动作可见。atomic 的卖点恰恰在这里：它本身也许只是一个门铃，真正的数据可能是一块被锁在门后的缓冲区。

2.3 acq_rel 和 seq_cst：从读改写一路到全局一致

memory_order_acq_rel 是 acquire 和 release 的叠加，语义上同时具备了读的 acquire 和写的 release。它几乎只在 read-modify-write 操作里有意义，比如 compare_exchange_weak、fetch_add、exchange。这类操作既读旧值又写新值，如果只是单纯地想读，就没有必要写；如果只想写，也没必要读。所以 acq_rel 常用于无锁链表的插入、自旋锁的抢锁，或者实现一些需要“拿旧值 + 更新新值 + 同步两侧”的算法。

memory_order_seq_cst 则是默认档位。它的全称是“顺序一致”，意思是对所有使用 seq_cst 的 atomic 操作，存在一个全局唯一的总顺序。你可以理解为：全系统里仿佛有一条所有人共享的时间线，每个 seq_cst 操作在这条时间线上都有明确先后。多线程对一个 seq_cst 变量连续读，读到的值的变化顺序在所有线程看来都是一致的。

提示：默认的 std::atomic 操作不写 memory_order 参数，就等价于 memory_order_seq_cst。新人阶段直接用默认值，通常不会错。只有在性能分析告诉你“这里确实是瓶颈”之后，再去考虑降级成 acquire/release 甚至 relaxed。

2.4 x86 与 ARM 上同一份代码的待遇

为什么很多人一开始学内存序总觉得“顺序问题的例子根本复现不出来”？因为大部分人开发环境是 x86。

x86 是强内存序架构，对常见的 load-load、load-store、store-store 都有较强的顺序保证，唯一可能出问题的是 store-load 重排。所以两个线程相互等对方 flag 的经典死锁/活锁问题在 x86 上稍微好复现一点，而“读标志位后再读普通数据”的类型错误反而不太容易触发。

ARM、PowerPC、RISC-V 这些弱内存序架构则大不相同。CPU 为追求低功耗和高吞吐，允许更大范围的乱序；缓存模型也更复杂。同一个 C++ 程序，在 x86 上可能跑了几年都没事，放到 ARM 上第一周就崩。这不是代码里的原子性错误，而是顺序假设从未被真正验证过。

因此，写跨平台多线程代码时，永远不要以“我的机器上能跑”作为标准。内存序的设计不是为了讨好 x86，而是为了让代码在任意合法平台上都有一致的语义。

3. acquire 和 release 必须成对出现：常见误用与前因后果

3.1 参数贴对了位置，不等于语义成立

很多人刚开始用 memory_order 时，以为只要 store 用 release、load 用 acquire 就万事大吉。其实还需要一个前提：load 必须真正读到 store 写入的那个值。

看一个例子：

cpp复制std::atomic<int> flag{0};
int value = 0;

// 线程 A
value = 1;
flag.store(1, std::memory_order_release);

// 线程 B
if (flag.load(std::memory_order_acquire) == 1) {
    assert(value == 1);
}

没问题，B 如果读到 1，则 A 的 release 和 B 的 acquire 配对成功。

但如果是这样：

cpp复制// 线程 A
value = 1;
flag.store(1, std::memory_order_release);

// 线程 B
if (flag.load(std::memory_order_relaxed) == 0) {
    // ...
}

B 用了 relaxed 读，读到的值哪怕恰好是 1，它也没有 acquire 语义，不能建立同步。代码在 B 的后续操作中读取 value 时，依然存在数据竞争风险。

再反过来看：

cpp复制// 线程 A
value = 1;
flag.store(1, std::memory_order_relaxed);

// 线程 B
if (flag.load(std::memory_order_acquire) == 1) {
    assert(value == 1);  // 依然不能保证
}

A 的 store 是 relaxed，没有 release 语义。B 纵使带 acquire，也无法“接住”另一个线程没有发出的信号。acquire 和 release 必须是一对一配对的同步原语，缺了任何一边，另一边都是空转。

3.2 两个独立生产者会让 acquire 失效吗

这里有个容易想当然的问题：如果一个线程只做 release store，另一个线程只做 acquire load，那么所有带 release 的写是否都能被带 acquire 的读看到？

答案是：只有当 load 读到的值来自那个 release store 时，两者之间才建立同步关系。如果 A 线程 release 写 flag = 1，B 线程随后 acquire 读 flag 读到的是另一个线程 C 写的 flag = 2，那么 A 和 B 之间未必同步。最简单的建议就是：在写代码前，在注释里写明“这个 acquire 是为了接住哪一次 release”，如果写不出来，说明模型有问题。

3.3 一个我踩过的 release sequence 小坑

后来在写一个并发队列时，我遇到过一个更隐蔽的问题：A 线程 release 写了一个节点的指针，B 线程通过 fetch_add 做了读改写，然后 C 线程再去 acquire 读。最初我以为 C 必须直接读到 A 的 release 才能同步，导致一度不敢在中间让别的线程做任何 RMW 操作。

查了标准才确认，C++ 定义了一个叫 release sequence 的机制：一旦某个 release 写被一个读改写操作链观察并修改，这条链上的后续 RMW 操作会延续 release 的“同步资格”。也就是说，只要某个线程通过 RMW 读到了 A 的 release store，并把结果继续写下去，后续 acquire load 读到链上任意一环的值，都能和最初的 release 建立同步。

这个机制的实用意义很大：无锁队列的 tail 指针经常被多个线程通过 CAS 修改，消费者并不需要直接读到最原始的 release store，也能安全地看到生产者写入的数据。

注意：release sequence 只对“读改写操作”有效，普通 store 不会延续它。如果一个中间线程只是简单地 store 一个新值覆盖 flag，那原有的同步关系就断了。

4. 为什么有人用 fence 代替原子操作自带的内存序？

atomic 操作自带 memory_order 是最常见的用法。但在一些性能敏感代码里，你会发现有人用 std::atomic_thread_fence 而不是在每次 store/load 里写 acquire/release。这不是炫技，而是 fence 能提供更细粒度的控制。

4.1 fence 给了我一个“统一点”

atomic 操作里的顺序约束是跟随变量走的。假设我有三个标志位，都要在数据写完后再发布，那么标准写法是给每个 store 都加 memory_order_release：

cpp复制data = 42;
flag1.store(true, std::memory_order_release);
flag2.store(true, std::memory_order_release);
flag3.store(true, std::memory_order_release);

三个 store 都带 release 语义。每个 store 发布时，都隐含一层屏障。如果这些标志的存储非常频繁，理论上你可以在更“宏观”的位置只放一个释放栅栏，让它一次性覆盖前面所有普通写。

更核心的一点：atomic 操作上的 ordering 约束通常绑定在“同一变量”的读写上，而 fence 是线程级别的，不绑定某个特定变量。它适合用在“我要把一大批共享状态的修改统一对外暴露”的场景。

4.2 fence 与 relaxed 配合的典型写法

fence 最经典的使用是配合 relaxed 原子操作完成同步：

cpp复制std::atomic<bool> flag{false};
int data = 0;

void writer() {
    data = 42;                                    // 普通写
    std::atomic_thread_fence(std::memory_order_release); // 发布屏障
    flag.store(true, std::memory_order_relaxed);  // 只做通知
}

void reader() {
    while (!flag.load(std::memory_order_relaxed)) {}
    std::atomic_thread_fence(std::memory_order_acquire); // 获取屏障
    assert(data == 42);
}

关键点在这里：writer 的 flag.store 是 relaxed，它本身并不携带 release 语义，但位于 release fence 之后。reader 的 flag.load 同样是 relaxed，但它在 acquire fence 之前。当 reader 读取到 true 时，writer 的 release fence 和 reader 的 acquire fence 形成同步，于是 data = 42 这个写在 reader 看来是可见的。

对比普通写法：

cpp复制flag.store(true, std::memory_order_release);
// reader 侧
flag.load(std::memory_order_acquire);

理论上，上面这对写法要表达的意思和 fence 版本基本等价。fence 版本的优势是：你可以进一步把“通知操作”和“真实数据发布”解耦。例如 writer 里在同一个 release fence 之后连续 store 多个 relaxed 标志，统一放行；reader 侧也可以在一次 acquire fence 之后统一处理多个标志读到的结果。

不过这里要提醒一句：fence 用起来的理解成本更高，也更难 review。它适合那种“你很清楚自己在为什么创建同步点”的场合。如果一个普通的 store release / load acquire 已经能解决问题，完全没必要去写 fence。我自己的倾向是，fence 只在无锁数据结构的批量发布、跨线程启动批次等场景使用，日常业务多线程代码里基本用不到。

5. 真实项目里到底怎么选：从有锁到无锁的落地判断

读了不少理论之后，更现实的问题是：实际代码里，什么时候要用 memory order，用哪一档。

5.1 已有 mutex，那就不该碰 atomic

如果两个线程之间共享一个可变状态，最“笨”也最稳的方案是 std::mutex 加锁。很多刚从线程池入门的开发者会想：“mutex 太慢了，我用 atomic 是不是更高性能？”这个想法的前提是：你已经证明了锁竞争是热点，并且你接受后续在无锁算法上付出的复杂代价。

mutex 内部其实也是基于原子变量实现的。它天然提供了 acquire/release 语义：加锁是 acquire，解锁是 release。临界区里所有的写操作，在锁释放后，对下一个成功加锁的线程可见。所以当你用了 mutex、condition_variable、future、async 这类高层同步原语时，其实不需要再手动关心 memory_order。

注意：这里有一个隐性好处容易被忽略——用 mutex 时，临界区内的普通变量读写是安全的，不会构成数据竞争。而如果不用 mutex，只靠 atomic 去保护普通变量，需要你自己把 acquire/release 的配对标清楚，一旦漏了就是 UB。

5.2 SPSC 队列：为什么 release/acquire 够了

最近几年无锁队列很流行，尤其是单生产者单消费者（SPSC）的环形队列。它的核心问题往往是“生产者写入数据后，消费者怎么知道数据已经写好了”。

如果用 mutex 实现，逻辑很简单：push 时 lock，写入，unlock。但某些高频场景下，用两个原子变量控制读写位置可能更好。典型写法是：

• 生产者更新写索引，store 时用 memory_order_release；
• 消费者通过 acquire load 读索引，确认数据已经准备好。

这里不需要 seq_cst，因为消费者的操作序列是固定的：先 acquire 读索引，再读环形缓冲区里的 data。生产者也是先写 data，再 release 更新索引。release/acquire 的配对刚好覆盖了整个链路。

如果换作多个生产者，事情不会变复杂太多，但会引入 CAS、fetch_add 竞争处理，你需要维护“哪个生产者的数据入队了”的状态，这时内存序的选择也需要重新审视。

5.3 shared_ptr 的计数并不需要对象级别的同步

还有一个很多人忽略的场景：shared_ptr 的控制块引用计数。

标准库实现里，引用计数的增减通常用的是 relaxed，可能配合 acq_rel 或 release 来保证对象析构的可见性。为什么计数本身不需要 seq_cst？因为“引用计数减到 0”和“对象销毁”之间有明确的某种同步关系，而不是说所有线程在任何时候看到计数值都必须一致。

自己写 shared_ptr 类似物时最容易犯的错误是：把所有 fetch_add/sub 都改成 seq_cst，觉得这样最安全。实际上，引用计数的真正难点在于最后一个引用释放时，需要保证之前所有对对象的使用都结束，并且对象的析构不能和仍在使用它的线程并发。这个正确性不依赖“所有线程看到的计数都一样”，而是依赖“最后一个释放者能看到前一个释放者的写操作”。

如果只是单纯统计“当前有多少个智能指针指向这个对象”，用 relaxed 足矣。如果计数还承担“决定谁来销毁对象”的职责，析构路径上就必须有 release/acquire 配对的同步。

标准库把这些细节都封装好了，尽量用标准智能指针，别自己实现。

6. 偶发 Bug 排查实录：从“看不出问题”到定位到乱序

很多人在实际项目里真正意识到内存序的重要性，是在遇到一个“怎么都复现不了”的偶发 bug 之后。我经历的某一个 bug 大致是这样的：线上服务偶尔出现配置数据不完整，进程重启后恢复。代码逻辑简单到不行：一个线程加载配置，写入全局结构后置 ready 标志；另一个工作线程等 ready 后读取。x86 测试环境里无论如何压测都过，ARM 设备上概率出现。

6.1 用 ThreadSanitizer 把数据竞争变成现场证据

当时第一件事不是猜内存序，而是让工具说话。ThreadSanitizer（TSan）能检测数据竞争，也就是两个线程在没有同步关系的情况下同时访问同一块内存，至少有一方是写。

编译命令加上：

bash复制g++ -fsanitize=thread -g -O1 main.cpp -o main

跑一遍原来很难复现的测试，TSan 会明确指出哪一行和哪一行之间存在 data race。如果代码里两个线程并发读写普通变量，且没有 mutex 或合适的 atomic 操作建立同步，TSan 几乎都能抓出来。

有一点要注意：TSan 不是运行时调优工具，编译时如果开 O2 或 O3，部分检查可能被优化影响，建议用 O1 或 O2 都可，但必须保留 -g。另外 TSan 目前不支持在部分环境下与某些其它 sanitizer 共用，如果项目用了自定义汇编或特殊链接器，需要先在小模块里验证可用性。

6.2 在汇编里看编译器做了什么手脚

TSan 报了 race 之后，再去理解“为什么 release/acquire 能解决问题”会更直观。如果想看编译器到底生成了什么，可以反汇编核心函数：

bash复制g++ -std=c++17 -O2 -S main.cpp -o main.s

重点搜索标志位的 store/load 附近有没有 barrier 指令。在 ARM 上，带 acquire 的 load 通常对应 ldar，带 release 的 store 对应 stlr；在 x86 上，seq_cst store 可能伴随 mfence 或 xchg，而 acquire load 因为 x86 本身有相对较强的顺序保证，可能只是普通 mov。

这些细节会提醒你：内存序的最终落实，依赖编译器与 CPU 架构共同配合。你写的不是“程序顺序不变”的保证，而是把同步需求告诉编译器和 CPU，让它们决定用什么底层指令满足你。

6.3 每一处原子操作都该有一句注释

排查过几次这类问题后，我给团队定了一条约定：任何非默认 memory_order 的 atomic 操作，旁边都必须写注释说明“这个 release 是要发布什么”“这个 acquire 是为了接住哪一个写”。

例如：

cpp复制// 发布配置版本号；读者只有看到新版本号后，才能安全读取新配置块
configVersion.store(v, std::memory_order_release);

这并不是形式主义。写注释的过程是在强迫自己回答“同步关系到底是什么”。如果答不上来，那这里大概率用了错误的内存序。

另外建议在代码 review 时把内存序当作高危改动看待。放松 memory_order 能带来一点性能提升，但可能换来的是只在弱内存序平台上才爆发的偶发问题。任何“去掉 memory_order_release 好像也跑得挺好”的结论，都不该成为改代码的理由。

在我个人经验里，绝大多数业务多线程代码并不需要用到 relaxed 甚至 seq_cst 以下的优化。先把同步语义写在注释里，用默认的顺序一致性跑通，再通过性能分析确认瓶颈，最后才考虑降级，这是最稳妥的路径。内存序是一个“平时不遇事，遇事就是大问题”的领域，多花点时间把模型想清楚，远比临时抱佛脚去查八股文有用。