汇编不会撒谎：为什么 volatile 共享变量换不来一条屏障指令？

在云栈社区的技术讨论中，volatile 的误区总是反复出现。一个流传了二十年的说法是：volatile 让变量“每次都从内存读、每次都写回内存”，所以两个线程之间用它当标志位是安全的。

这句话前半句在编译器层面大致成立，后半句是错的——而且错得很彻底。错的根源在于，它把两件发生在不同层级的事情混成了一件：volatile 约束的是编译器和 C++ 抽象机之间的关系，而线程同步要约束的是一个 CPU 核心和另一个 CPU 核心之间的可见性与顺序。这两个战场隔着整个内存层级，volatile 只站在最上面那层。

把这句话拆到底，你会发现一个几乎荒诞的事实：给一个共享 int 加上 volatile，在 x86 上编译器吐出来的仍然是一条普普通通的 mov——和不加 volatile 唯一的区别是这条 mov 不会被删掉、不会被合并。它前面没有 mfence，后面没有 lock 前缀，store buffer 不会因为它刷新，缓存一致性协议不会因为它提前收敛。它禁止了一类优化，却没有换来任何一条屏障指令。 原子性和内存序——线程同步真正依赖的两样东西——恰好都落在它够不到的地方。

as-if 规则划定的边界：volatile 访问是抽象机必须原样吐出的可观察副作用

要讲清 volatile 禁止了什么，得先讲清编译器默认被允许做什么。

C++ 的一切优化建立在 as-if 规则上（标准 [intro.abstract]，旧版本里叫 [intro.execution]）：只要程序的可观察行为不变，编译器可以对代码做任意变换——删除、合并、重排、向量化、把整个循环算成一个常量。而“可观察行为”被定义得很窄，只包括两样：对 volatile 对象的访问，和库 I/O 函数的调用。换句话说，一个 volatile 访问，按定义就是编译器必须原样发射、不得增删、不得与其他可观察副作用换序的一个点。

标准对 volatile 语义的正式描述只有一句话（[dcl.type.cv]）：“volatile is a hint to the implementation to avoid aggressive optimization involving the object because the value of the object might be changed by means undetectable by an implementation.”——它是一个提示，告诉编译器“这个对象的值可能被你察觉不到的手段改掉，别做激进优化”。注意措辞：避免激进优化。整条语义是关于优化的，一个字都没提到线程、原子、可见性。

落到具体代码，volatile 禁掉的是这几类变换。最经典的是把 load 提到循环外：

// GCC 13 / Clang 17, -O2
int   flag = 0;              // 普通变量
void wait(){ while (!flag) {} }   // 期望别的线程把 flag 置 1

编译器读到这段，会推理：“在这个线程里，循环体没有任何东西修改 flag，那 flag 每次迭代都是同一个值。” 于是它把 load 提到循环外，等价于：

void wait(){
    int tmp = flag;          // load 一次
    if (!tmp) for (;;) {}    // 剩下的是死循环
}

生成的汇编里，循环体是一条 jmp .L2 打死转——flag 后来变不变，这个线程永远看不到。把 flag 改成 volatile int，情况反转：每次访问都是可观察副作用，编译器被迫在每次迭代重新发一条 load：

.L3:
    mov     eax, DWORD PTR flag[rip]   ; 每轮都重读，不能提出去
    test    eax, eax
    je      .L3

这就是“每次都从内存读”的真身——它是一条关于代码生成的保证：编译器不许把这个 load 缓存进寄存器、不许跨迭代复用。同理它也禁掉 dead store elimination（连写两次 v=1; v=1; 两条都得留）、禁掉把相邻访问合并成一次。这些都是实打实的、有用的保证。

但请把这句话的边界看死了：它保证的是编译器会发出这条 load，而不是这条 load 能读到别的核刚写的值。前者是编译期的事，后者是运行期跨核的事。volatile 只签了前一张合同。

它没禁止的：非 volatile 访问可以自由地从它头顶重排过去

真正致命的漏洞不在“它保证了什么”，而在“它明确没有保证什么”。标准只规定了 volatile 访问之间不得互相重排，对volatile 访问和普通访问之间的顺序只字未提。这句话是整个“volatile 不能同步”论证的枢纽。

看这段所有人都写过的发布模式：

int          payload;        // 普通变量：真正要传的数据
volatile bool ready = false; // volatile 标志：告诉消费者数据好了

void producer(){
    payload = 42;            // (1) 写数据
    ready   = true;          // (2) volatile 写，发布
}
void consumer(){
    while (!ready) {}        // (3) volatile 读，等待
    use(payload);            // (4) 读数据
}

直觉是：ready 是 volatile，编译器不敢动它，所以 (1) 一定在 (2) 之前、(4) 一定在 (3) 之后。第一个判断就错了。(1) 是对普通变量 payload 的写，它不是可观察副作用；as-if 规则允许编译器把它挪到 (2) 之后——只要在本线程看来结果一样，而本线程确实看不出区别。于是消费者可能读到 ready == true，payload 却还是旧值。编译器合法，你的程序错了。

有人于是把 payload 也改成 volatile。这确实堵住了编译器层面的重排：两个 volatile 访问之间标准不许换序。但你只是把问题从编译器层踢到了硬件层——而硬件层根本不认识 volatile 这个 C++ 关键字。CPU 的 store buffer 会让 (1) 的写在 (2) 之后才对其他核可见（x86 的 TSO 下 store-store 不重排，但 ARM/POWER 下会）；consumer 侧的乱序执行会让 (4) 的 load 在 (3) 之前就投机发射。volatile 生成的汇编里没有任何东西阻止这些——因为它没生成任何屏障。

这里有个我反复跟人强调的分层：编译器重排和硬件重排是两道独立的闸门，volatile 顶多关得上第一道，第二道它连门把手都摸不到。 而线程同步需要两道全关。这也是为什么“把所有共享变量都标 volatile”这种做法，在强内存模型的 x86 上能骗过测试、一上 ARM 就现原形——不是 volatile 变弱了，是它从来就没管过第二道闸门，只是 x86 恰好帮它把第二道闸门默认关上了。

汇编不会撒谎：volatile 和 atomic 差的正是那条屏障

把 volatile 和 std::atomic 生成的代码摆在一起，差别一目了然。这是全篇最硬的一条证据，因为它不依赖任何标准条文的解读——objdump 出来是什么就是什么。

volatile int   v;
std::atomic<int> a;

void store_v(){ v = 1; }                                 // volatile 写
void store_a(){ a.store(1, std::memory_order_seq_cst); } // atomic 顺序一致写

x86-64（GCC 13, -O2）下：

store_v:
    mov     DWORD PTR v[rip], 1        ; 就一条普通 mov，完事
    ret
store_a:
    mov     DWORD PTR a[rip], 1
    mfence                             ; 多了一条全屏障
    ret

store_v 和一个非 volatile 的赋值在指令上完全相同，唯一区别是编译器承诺不删它。而 store_a 多出来的那条 mfence，才是同步的本体——它强制把 store buffer 排空、禁止后续 load 越过它投机。ARM64 上区别更直白：volatile 写是普通 str，atomic release 写是 stlr（store-release），atomic acquire 读是 ldar（load-acquire），stlr/ldar 是硬件级的单向屏障指令，str/ldr 不是。

结论摆到台面上：volatile 从不生成屏障指令，而内存序的全部实现手段就是屏障指令。 一个不发屏障的东西谈何提供内存序。它俩根本不在一个抽象层——volatile 活在“编译器要不要保留这次访问”这一层，内存序活在“这次访问对别的核何时可见、以什么顺序可见”那一层。

原子性的缺口是另一道独立的坑，和内存序无关。volatile 不保证访问不可分割：

volatile int64_t counter;  // 32 位平台
counter = 0x1'0000'0001;   // 一次写，可能拆成两条 32 位 store

在 32 位目标上，这个 64 位写会被拆成两条 mov，另一个核可能读到只更新了一半的中间态（torn read）。volatile 一个字都没管。更常见的是读-改-写：

volatile int n;
n++;                       // load n → +1 → store n，三步，不是一步

n++ 编译成 load、加一、store 三条指令，volatile 保证每一条都发出去、不被优化掉，但三条之间没有任何锁。两个线程同时 n++，各自 load 到同一个旧值、各自加一、各自写回，一次自增就这么丢了。而 std::atomic<int>::fetch_add 在 x86 上是一条带 lock 前缀的 lock add，硬件保证这条指令不可分割。差的又是那条前缀。

标准委员会自己也认了这个坑：C++20 的 P1152（JF Bastien，Deprecating volatile）废弃了 volatile 对象上的复合赋值和自增自减（v += x、v++ 这类），理由正是这些读-改-写形式在语法上看着像一步、实则三步，长期误导人以为 volatile 自增是原子的。委员会宁可把这些写法标记为 deprecated，也不愿它继续散播“volatile ≈ 原子”的错觉——但它没动 MMIO 那类单次 load/store 的用法，因为那才是 volatile 的正当领地。这条演进本身就是一份官方判决：volatile 和原子性从来是两回事。

再往形式化推一层，volatile 用于同步不只是“慢”或“偶尔出错”，它在标准里是未定义行为。[intro.races] 定义数据竞争：两个访问冲突（至少一个是写、访问同一内存位置）、至少一个非原子、且不被 happens-before 关系排序——就是数据竞争，行为未定义。而 happens-before 只能由原子操作或互斥量建立（[atomics.order] 的 release-acquire 语义）；volatile 访问不参与这个关系。所以两个线程用 volatile 变量通信，只要有一方写，就精确落在数据竞争的定义里，是 UB。不是“在弱平台上会错”，是标准层面就没给你任何保证，编译器可以假设它不发生。

“在 x86 上跑了两年”的代码，赌对的是两个巧合

那为什么无数用 volatile 当标志位的代码，真的在生产里跑了很多年没出事？因为 x86 替它兜了两次底，而这两次兜底都不是 volatile 的功劳。

第一次兜底是内存序：x86 是 TSO（Total Store Order）模型，store-store 不重排、load-load 不重排，唯一允许的重排是 store 之后的 load 提前（store-load）。producer/consumer 那个发布模式，恰好只需要 store-store 和 load-load 有序，x86 硬件默认就满足。第二次兜底是原子性：自然对齐的机器字（32 位平台上的 4 字节、64 位平台上的 8 字节）在 x86 上的单条 mov 本就是原子的，虽然标准不保证，但硬件事实如此。

于是 volatile 只需要干成它唯一能干的那件事——不让编译器把 load 优化掉——剩下的可见性和原子性 x86 全包了。两个巧合叠在一起，代码就“对”了。可这份正确性一步都经不起挪动：换到 ARM/POWER，第一次兜底没了；用到跨机器字或 RMW，第二次兜底没了；哪怕还在 x86，只要像上一节那样把普通变量的写混进来让编译器重排，兜底也漏了。

我经手过一次这样的漏。一个推理服务里，多个 worker 线程各自处理请求，用一个共享计数器统计总吞吐 token 数，写代码的人图省事声明成 volatile uint64_t processed_tokens，各线程 processed_tokens += batch_tokens。功能测试、压测都过了，上线后运营发现日报里的 token 总数和计费系统对不上，长期偏低约百分之几，负载越高偏得越多。查了很久内存序、查了 NUMA，全是错方向——根因是 += 那个读-改-写不是原子的，高并发下两个 worker 的自增互相覆盖，丢的更新量正比于竞争强度。这个坑和内存序毫无关系，纯粹是原子性缺口，而 volatile 在这两件事上都帮不上忙，只是让每一条 load/store 都忠实地发了出去——忠实地把错误也发了出去。换成 std::atomic<uint64_t> 的 fetch_add(relaxed)，一行改动，偏差归零。这里连内存序都不需要 seq_cst，relaxed 足够——计数只要原子，不要顺序。

volatile 真正的归属：单线程里那些“编译器看不见的手”

把 volatile 从线程同步里赶出去，不等于说它没用。它有一块无可替代的自留地——凡是“值会被当前线程的普通代码流之外改掉、但又不涉及第二个 CPU 核”的场景，volatile 正是为此而生。

最正统的用途是 MMIO（内存映射 I/O）。一个设备寄存器映射到某个地址，硬件会在你不知情时改写它，你的读写会触发设备动作：

// 设备状态寄存器映射在此地址
volatile uint32_t* const STATUS = reinterpret_cast<volatile uint32_t*>(0xFED0'0000);
while ((*STATUS & DEVICE_READY) == 0) {}  // 轮询硬件置位

这里 volatile 不可或缺：编译器若把 *STATUS 缓存进寄存器，你就永远等不到硬件置位——和那个死循环 bug 同构，只不过这次改值的“另一只手”是硬件而非另一个线程。同理，连写两次同一寄存器（有些设备靠“写两次”触发时序）也绝不能被合并成一次。这正是 volatile “不删、不合并、不缓存”三条保证的用武之地，且全程只有一个 CPU 核在参与，不需要任何屏障。

第二块是信号处理。异步信号会在同一线程的执行流里“插进来”改掉一个变量，volatile sig_atomic_t 保证 handler 的写不被主流程优化掉、且访问在单线程内不可分割：

volatile sig_atomic_t g_stop = 0;
void on_sigint(int){ g_stop = 1; }        // handler 里改
int main(){ while (!g_stop) work(); }     // 主流程读

注意 sig_atomic_t 的“atomic”是单线程内相对于信号的原子，不是跨线程的原子——它同样不能用于多线程同步。setjmp/longjmp 之间需要保活的局部变量也是类似道理：控制流会以编译器无法静态追踪的方式跳走，volatile 阻止它把这些变量优化进寄存器。

Linux 内核给了这套思路最干净的示范：它几乎不直接用 volatile 声明变量（volatile-considered-harmful.rst 明说“其目的是抑制优化，而这几乎从来不是你真正想要的”），而是把 volatile 收窄成两个宏 READ_ONCE/WRITE_ONCE（include/asm-generic/rwonce.h），本质是对一次访问做 volatile 强制转换。它们只干一件事：防止编译器把这次 load/store 优化掉或撕裂（load/store tearing），顺序问题交给显式屏障 smp_rmb/smp_wmb/smp_mb 或原子操作去管。

这是全篇最该记住的方法论：内核把 volatile 混在一起的两件事拆开了——“别优化掉这次访问”用 READ_ONCE（volatile 的活），“让这次访问对别的核有序可见”用屏障（volatile 干不了的活）。而把 volatile 当同步用，恰恰是指望一个只会干第一件事的工具，去干它压根没参与的第二件事。

需要跨线程可见性时，该伸手去拿什么

如果你现在手里有一段 volatile 标志位跨线程的代码，替换路径很清晰，按你到底需要哪样能力来选，而不是无脑全改 atomic。

需要跨线程的可见性 + 顺序（绝大多数同步场景）：换 std::atomic<T>，按需选 memory order。发布数据用 release/acquire 配对，ready.store(true, release) 保证之前所有写（包括那个普通 payload）对读到 acquire 的线程可见——这正是 volatile 给不了的 happens-before。代价是一对屏障指令，release 在 x86 上甚至不额外发指令（TSO 白送），acquire 也是；只有 seq_cst 才在 x86 上吃一条 mfence。多数场景 release/acquire 够用，不必默认 seq_cst。

只需要“别撕裂、别被编译器凭空发明或删除”、顺序我自己用屏障管：用 std::atomic_ref<T> 配 relaxed，或在内核语境里用 READ_ONCE/WRITE_ONCE。这是把内核那套“两件事拆开”搬到用户态。

只需要单线程内应对信号/硬件/longjmp：volatile 留着，它就是干这个的，别改。