C++原子操作底层原理：从std::atomic到MESI缓存一致性协议

如果你在多线程程序里用 std::atomic<int> 跑一段自增循环，再拿它跟 std::mutex 保护的版本做性能对比，很容易产生一种错觉：原子操作几乎不加锁。这个错觉恰恰是很多人把 C++ 原子操作用坏的起点。

原子操作不是没有锁，而是把锁下沉到了 CPU 指令和缓存一致性协议这一层。它相当于把钥匙交给硬件，让硬件替你在更短的时间里完成“锁门开门”的动作。作为一个写了十几年 C++ 的老程序员，我被 std::atomic 这种“貌似免费”的表象坑过不止一次。计数器在并发下少算、自旋锁死循环、无锁队列莫名其妙丢节点，这些问题最后都指向同一个根因：我并没有真正理解原子操作在底层是怎么实现的。

这篇文章要把 C++ 原子操作从头到尾剥开一次：从 i++ 为什么丢数据，到 MESI 缓存一致性协议，再到 x86 的 lock 前缀和 ARM 的 LL/SC 方案，最后落到 std::atomic 和 memory_order 的真实编译结果。适合那些已经会用 std::atomic，但还想知道“它凭什么能保证原子性”的人；也适合正被 ABA 问题、内存乱序问题折腾的排错选手。

1. 从被无数人写错的 i++ 说起

1.1 非原子读改写为什么不安全

先看一段最常见的“错误代码”：

cpp复制#include <atomic>
#include <thread>
#include <iostream>

int main() {
    int counter = 0;
    std::thread t1([&] { for (int i = 0; i < 100000; ++i) ++counter; });
    std::thread t2([&] { for (int i = 0; i < 100000; ++i) ++counter; });
    t1.join();
    t2.join();
    std::cout << counter << std::endl;
    return 0;
}

理论上两个线程各加十万次，counter 应该是 200000。但实际跑起来，结果往往是一个小于 200000 的数，而且每次运行都可能不一样。

原因在于 ++counter 在机器层面不是一个动作，而是三条指令：

assembly复制mov eax, [counter]   ; 把 counter 读入寄存器
add eax, 1           ; 寄存器加一
mov [counter], eax   ; 把新值写回内存

线程 t1 执行完 mov eax, [counter] 之后，操作系统碰巧切换到了 t2；t2 同样把旧的 counter 值读到自己的寄存器里加一写回；等 t1 再恢复执行时，它仍然拿着旧值加一写回。两次自增操作合并成了一次，计数器就少了。

这个场景里，++counter 是一个典型的“读-改-写”区间，它不是不可分割的。要保证正确性，就得让这个区间在并发环境下对外表现为一个原子步骤。

1.2 原子操作锁定的真正对象是缓存行

很多人第一次接触原子指令时，以为它在锁总线。早期 x86 确实会在原子指令执行期间拉高 LOCK# 信号，阻止其他核访问内存。后来 CPU 性能越来越强，锁总线太粗暴了，因为它会让所有核心都停摆，哪怕它们操作的完全是不同内存地址。

现代 CPU 的做法是：锁缓存行。

CPU 和内存之间隔着多级缓存，数据在缓存里按“缓存行”存放，一个缓存行通常是 64 字节。原子指令执行时，CPU 拿到包含目标数据的缓存行的独占权，在指令执行期间禁止其他核心对该缓存行做任何修改，操作完成后再释放。这样既保证原子性，又不会影响其他核心访问无关的缓存行。

这个思路和数据库的行锁很像：不是把整张表锁住，而是只锁你正在改的那一行。只不过 CPU 的“行锁”粒度是 64 字节的缓存行，不是某条数据。理解了这一点，你对“原子操作为什么这么快”就有了第一层认知：它没有调用系统调用，没有进入内核，只是让硬件在极短的时间内替你管理了一个缓存行的所有权。

2. 真正在底层保证原子性的是硬件机制

2.1 MESI 协议如何在多核之间协调缓存行

要让“锁缓存行”成立，CPU 之间必须有一套统一的规则知道谁持有缓存行、谁能改缓存行，这就是缓存一致性协议。用得最广的是 MESI 协议，名字来自缓存行的四种状态：

当一个线程执行原子自增时，CPU 会走这样一条链路：

1. 请求读取目标地址对应的缓存行。
2. 如果本核缓存里没有，就通过片上互联网络向其他核发起请求。
3. 如果其他核持有该缓存行，状态会变成 I；本核拿到缓存行副本后，可以是 E 或 S 状态。
4. 在执行原子写之前，CPU 要把缓存行状态转为 M，这一步需要获取独占权，同时向其他核广播“把这个缓存行失效掉”。
5. 等所有其他核心确认失效完成，在当前缓存行上执行读改写，整个过程被视为不可分割。

MESI 保证了多核最终能看到同一个值，但它本身不解决“顺序”问题。这就是为什么原子操作还经常要搭配内存屏障。

2.2 写缓冲和失效队列如何引入乱序

现代 CPU 为了提高效率，不会让每次写都立刻穿透到缓存直达内存。写入会先进入一个叫 store buffer（写缓冲器）的地方，CPU 继续执行后续指令，store buffer 再异步写回缓存。

store buffer 存在的时候，一个核心看到的写顺序和实际落在缓存里的顺序可能不同。再加上“失效队列”：当 CPU A 修改了一个缓存行并广播失效时，CPU B 可能把失效事件丢进队列，暂停处理，先继续执行自己手里的指令。在 B 看到失效之前，它读到的仍是旧值。

所以你会遇到一种情况：线程 A 写了一个变量，紧接着设置了一个标志位；线程 B 看到标志位为 true，但立刻去读那个变量，却读到旧值。这在 C++ 的内存模型术语里叫“重排”，它发生在硬件层，和编译器优化无关。

原子指令能保证单条指令的原子性，但要在“若干普通读写 + 原子操作”之间建立可见顺序，还必须借助内存屏障。这是理解后面 memory_order 的关键。

2.3 x86 的 LOCK 指令与 ARM 的 LL/SC 方案

不同指令集对“原子”的实现思路不一样。

x86 走的是粗放但简单路线：给指令加 lock 前缀。lock add dword ptr [rdi], 1、lock xadd、lock cmpxchg，这些指令执行期间，CPU 保证缓存行不被其他核触碰。因为 x86 是强内存模型（TSO），大部分普通读写本来就有较强顺序性，再加个 lock 就足够解决绝大多数场景。

ARM 走的是另一条路线：LL/SC（Load-Linked / Store-Conditional）。对应指令是 ldxr 和 stxr：

text复制loop:
    ldxr x0, [x1]      ; 读取目标地址，并标记该缓存行
    add  x0, x0, #1    ; 修改
    stxr w2, x0, [x1]  ; 条件写，如果标记的缓存行被改动过则失败
    cbnz w2, loop      ; 失败则重试

LL/SC 的精髓在 stxr：它返回一个状态位，告诉 CPU 这次条件写是否成功。如果在这期间有其他核心动过同一个缓存行，stxr 失败，线程只能重新读取、重新计算。

LL/SC 的好处是更灵活，代价是可能饥饿——如果竞争非常激烈，某个核心可能反复失败。不过在真实场景里，临界区足够短，失败概率通常可以接受。

3. C++11 标准库把硬件细节封装进 std::atomic

3.1 你真的理解 memory_order 是在调什么东西吗

很多人把 memory_order 当成原子操作的“强度档位”，以为选 memory_order_relaxed 会让原子变慢，选 memory_order_seq_cst 会让原子变快或更保险。这个理解方向是错的。

memory_order 和“原子性”无关。原子性由底层的 lock 前缀或 LL/SC 指令保证，无论你选哪种 order，单条读改写本身都是原子的。memory_order 决定的是：这个原子操作附近的其他内存操作，能不能越过它被重排。

C++11 提供了六种取值：

把 acquire 和 release 放在一起看：它们天然形成一对——release 写好数据，acquire 读到数据后，读到的数据才保证可见。这个你会在后面代码里看到。

3.2 三种主要内存模型的运行效果

我经常用一个不太严谨的比喻：relaxed 是一张写满字的纸，贴到墙上就完事；release 是“先做完手里的活，再贴纸”；acquire 是“看到纸之后，才允许开始后面的活”。

实际效果用代码来感受。下面是一个最常见的“发布-订阅”模式：

cpp复制std::atomic<bool> ready{false};
std::string message;

void producer() {
    message = "hello";
    ready.store(true, std::memory_order_release);
}

void consumer() {
    while (!ready.load(std::memory_order_acquire)) {
    }
    // 这里能安全读取 message，一定是 "hello"
    std::cout << message;
}

注意 message 是一个普通 std::string，不是原子的。但因为是先写入 message、再用 release 语义发布 ready，而消费者是用 acquire 语义观察到 ready 为 true，所以编译器、CPU 都不得把 message = "hello" 移到 ready.store 之后。这就是通过原子操作给非原子变量建立同步关系的核心用法。

如果这里两个原子操作都改成 memory_order_relaxed，程序大概率也能跑对，但这是“运气好”而不是“保证对”。在 ARM 这样的弱内存模型上，它真的可能读到空字符串。

memory_order_seq_cst 是最强的，默认值就是它。它等于同时带上 acquire + release，并且要求在系统内存在一个全局顺序：所有线程看到的所有 seq_cst 操作顺序完全一致。写到强一致性的地方用它不会错，成本也最高。

3.3 编译器重排和 CPU 乱序如何被拦截

内存屏障要阻止两类重排：一类是编译器在生成机器码时做的指令重排，另一类是 CPU 执行时的乱序执行。std::atomic 的库实现会在合适位置插入编译器屏障和硬件屏障。

x86 上，情况比 ARM 简单很多。因为 x86 的 TSO 内存模型天然不允许 StoreStore、LoadLoad、LoadStore 这三种乱序，只允许 StoreLoad 乱序。也就是说：

所以在 x86 上写 std::atomic 时，编译器经常能用更便宜的指令实现部分 memory_order，最典型的是：seq_cst store 在 x86 上可能被编译成 mov + mfence 或直接 xchg，而 release store 可能就是一条普通 mov，因为 x86 本身已经满足了 StoreStore 顺序要求。

在 ARM 上就没这么幸运了，必须显式插入 dmb（数据内存屏障）才能挡住乱序。这也是为什么同一套 C++ 代码，在 ARM 上可能发现内存顺序相关 bug，而在 x86 上测了很久都是好的。

4. 动手看：简单代码在 x86 和 ARM64 下编译成什么样

4.1 fetch_add 背后的 lock xadd

直接上代码：

cpp复制#include <atomic>

std::atomic<int> counter{0};

void inc() {
    counter.fetch_add(1, std::memory_order_relaxed);
}

用 gcc 在 x86-64 下编译，-O2，得到的核心指令是：

assembly复制lock add DWORD PTR [rip+counter], 1

lock add 一条指令解决。这里没有出现 xadd，是因为编译器发现我们只需要加一，不用拿旧值，于是直接用 lock add 优化掉了寄存器交换。如果需要返回旧值：

cpp复制int inc_ret() {
    return counter.fetch_add(1);
}

编出来通常就是：

assembly复制mov eax, 1
lock xadd DWORD PTR [rip+counter], eax

lock xadd 先交换再加法，拿旧值写新值，整个过程一步完成。你在 C++ 层写 fetch_add，底层就是这条指令。

4.2 ARM64 下的 ldxr/stxr 重试循环

同一个 inc()，在 ARM64 clang 下编译结果类似：

assembly复制.LBB0_1:
    ldaxr   w8, [x9]        ; 带 acquire 语义的 LL 读
    add     w8, w8, #1
    stlxr   w10, w8, [x9]   ; 带 release 语义的 SC 写
    cbnz    w10, .LBB0_1    ; 失败则重试

注意，当我把 memory_order_relaxed 改成默认 memory_order_seq_cst 后，ARM 侧读用了 ldaxr、写用了 stlxr，这两个指令本身携带了屏障语义。如果确实是 relaxed 版本，去掉 a 和 l 即可，循环结构不变。

这个循环就是 LL/SC 的真实面目：读、改、条件写、失败了再来。它不是单条指令完成任务，而是一个很短的重试循环。

4.3 观察不同内存序在 x86 上的“偷懒”

另一个值得观察的地方是 std::atomic<bool> 的 store/load。release store 在 x86 上经常只是一条普通 mov：

cpp复制std::atomic<bool> flag{false};

void set_flag() {
    flag.store(true, std::memory_order_release);
}

编译结果：

assembly复制mov BYTE PTR [rip+flag], 1

没有 lock、没有 mfence。因为 x86 本身不允许 StoreStore 重排，release 需要保证的“前面的写不能越过本次 release store”已经天然满足，编译器自然不用额外加指令。但如果你把 release 换成 seq_cst：

cpp复制flag.store(true, std::memory_order_seq_cst);

可能变成：

assembly复制mov eax, 1
xchg BYTE PTR [rip+flag], al

xchg 隐含 lock 语义，还充当了全屏障。所以你看到同样的“设置一个 bool”，不同 memory_order 对应的指令开销可能差距很大。这也是我在项目里常提醒团队的地方：默认 seq_cst 没毛病，但要在极热路径上追求性能时，可以先从 release/acquire 开始分析。

5. 无锁数据结构中的原子操作真实用例与经典陷阱

5.1 自旋锁：从原子标志位到临界区保护

一个经典型应用是用 std::atomic_flag 做自旋锁。std::atomic_flag 是所有原子类型中最底层的，标准库保证它一定是无锁的，适合做基础构件。

cpp复制class SpinLock {
public:
    void lock() {
        while (flag_.test_and_set(std::memory_order_acquire)) {
        }
    }

    void unlock() {
        flag_.clear(std::memory_order_release);
    }

private:
    std::atomic_flag flag_ = ATOMIC_FLAG_INIT;
};

test_and_set 对应硬件上的 “交换并设置” 原子操作。x86 上是 lock bts 或类似指令；ARM 上是 LL/SC 循环。它做的事是：把标志位设为 true，同时返回旧值。如果旧值是 false，说明锁空着，当前线程拿到了锁；如果旧值是 true，说明别人已经持有，继续自旋。

自旋锁的好处是快，不加系统调用，适合临界区极短、竞争不激烈的场景。代价是——如果一个线程持有锁后因为线程被切换出 CPU 而迟迟不释放，其他线程只能在原地空转，CPU 白白烧掉。所以任何在持锁期间调用 sleep、IO、锁嵌套的行为都是大忌。

5.2 ABA 问题：原子操作解决了原子性，没解决“内容没变”

如果你用无锁栈、无锁队列，迟早遇到 ABA 问题。我用无锁栈举例：

1. 线程 A 读取栈顶节点为 Node X。
2. 线程 A 准备执行 CAS：把栈顶从 Node X 换成 Node X->next。
3. 在 A 执行 CAS 之前，线程 B 把 Node X 弹出，又插入一个新节点，巧的是新节点的地址也是 Node X（内存被复用或者被再分配）。
4. 线程 A 的 CAS 比较栈顶地址，发现还是 Node X，于是 CAS 成功，但此时栈顶这个节点的内容已经被改过了，A 的后续操作拿到的数据是错的。

ABA 问题的本质是：CAS 只能保证“地址没变”，不能保证“地址指向的这个节点状态没变”。

解决方案常见有三种：

• 使用带版本号的原子指针，即“双词 CAS”：指针本身一个词，版本号一个词，两个词用 16 字节 CAS 同时比较。x86 上有 cmpxchg16b，C++ 里是 std::atomic 特化在多字结构上的 compare_exchange。
• 延迟内存回收，禁止节点在 ABA 窗口期内被重新分配，比如使用 hazard pointer 或 epoch-based reclamation。
• 避免在 CAS 失败路径上访问已被弹出的节点，坚持“重读栈顶再操作”。

我在自己的无锁队列实现里被 ABA 问题咬过一口，最后选择了双词 CAS + 版本号，而不是去赌分配器不会复用地址。宁可代码难看一点，也不要让正确性依赖巧合。

5.3 shared_ptr 的引用计数为什么快

你日常用的 std::shared_ptr，每次拷贝都要递增引用计数，这个递增就是原子操作。控制块里通常有一个 std::atomic<long>，拷贝时调用 fetch_add，析构时调用 fetch_sub，归零时释放资源。

正因为用的是 fetch_add 而不是 mutex，shared_ptr 拷贝才能那么快。x86 上一次 lock xadd 才几个纳秒，直接做成无锁操作。这也是标准库里原子操作最成功的应用之一。

但这里有个极容易误解的“坑”：shared_ptr 的线程安全只保证“不同线程各自持有同一个 shared_ptr 的副本”时，引用计数安全。如果你在多线程里同时调用同一个 shared_ptr 对象的非 const 成员函数，比如直接对同一个对象做 shared_ptr<T> p2 = p1;，这仍然是未定义行为，因为 p1 本身的拷贝不是原子的。正确做法是先拷贝到局部变量，再把局部变量传给线程。

6. 我的排错经验：什么时候该用原子，什么时候该老实上锁

6.1 原子操作和 mutex 的性能差距到底有多大

我用一个四核 x86 Linux 机器测过三种自增方式：

无竞争时 std::mutex 的 lock/unlock 也是很快的，因为现代 mutex 有 fast path。可一旦发生竞争，互斥锁会让线程 sleep，未来被唤醒又需要内核参与，这个开销远远超过原子指令。所以在“超大并发下频繁修改单个变量”的场景，atomic 几乎是唯一合理选择。

反过来，如果你的临界区里要做几十行复杂运算、要操作容器、结构体、可能有 IO，那 atomic 就帮不上什么忙了——它只能保护单一目标数据，不能保护一大段代码。这时候硬用 atomic 做各个标志位，反而把数据一致性拆得七零八落，容易出 bug。

6.2 排查原子操作中两个最容易踩的坑

第一个坑是“原子性不等于可见性”。我曾经遇到过一个后台线程改了一个配置开关，主线程一直看不到新值。排查到最后发现配置开关用的是普通 bool，加上 volatile 也没用。正确方案是改成 std::atomic<bool>，并且在读端使用 acquire、写端使用 release。volatile 在这里只解决“编译器优化掉读取”，不解决“CPU 缓存不一致”和“乱序”。

第二个坑是“compare_exchange 的逻辑写反”。很多人第一次写无锁更新，把 compare_exchange 的期望值和期望更新的顺序搞反：

cpp复制int expected = val.load();
int desired = expected + 1;
while (!val.compare_exchange_weak(expected, desired)) {
    desired = expected + 1;
}

这里关键在于 compare_exchange_weak 失败时会把 expected 更新成当前的观察值，所以循环里不用再手动 load。但新手经常在 while 体里重新写 expected = val.load()，导致每次循环多一次 load，虽然不是错，但会影响性能。另一个更隐蔽的问题：用 strong 还是 weak？在循环重试场景里用 weak 更合适，因为某些架构上 strong 实现更昂贵，weak 允许因伪失败而更早重试。

排查这两类问题时，编译器的 ThreadSanitizer 很有用：

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

它能在运行时测出数据竞争，强烈建议在 CI 里跑一遍。再配合 Godbolt（godbolt.org）看汇编，就能确认哪些原子操作真正变成了原子指令。

6.3 我整理出的几条选型原则

这些年用下来，我给自己定了几条规矩：

1. 能用标准库容器 + mutex 解决的，不要碰无锁结构。 无锁数据结构的难点不只是正确性，还包括内存回收、ABA、顺序建模，复杂度远比想象中高。
2. 原子操作只用于单一变量、单一标志位、引用计数这类简单场景。 如果你发现临界区逻辑超过十行，直接切回 mutex。
3. memory_order 先用默认 seq_cst 写对，再考虑优化。 性能瓶颈要用 profiler 证明，不要上来就一发 relaxed。否则只能理解为“我在用正确性赌性能”。
4. 打开 ThreadSanitizer。 它抓不到全部问题（比如 ABA），但能抓到你睡觉时最容易犯的数据竞争。
5. 如果你有 x86 和 ARM 双平台，优先在 ARM 上做内存相关测试。 弱内存模型更容易暴露顺序问题。

如果你也是从“我不过是想让计数器准确一点”开始接触原子操作的，我劝你别停在 std::atomic<int> 这么浅的用法上。抽一晚上时间，把 lock 前缀和 LL/SC 的汇编输出看一遍，把 memory_order_release/acquire 的手写同步代码跑一遍，收益会比背一堆面试题大得多。

至少对我个人而言，真正把底层机制想清楚之后，再回来看 std::atomic，每一行代码都踏实了很多——我知道它不会在关键时刻“偷偷重排”，也知道该在什么场景乖乖换回一把普通的锁。