① 钩子三条一模一样的 movl同一段读一个 int的代码volatile、普通变量、std::atomic编译出来一模一样——都是movl (%rcx), %eax一条指令。那为什么volatile对多线程没用因为单条读是原子指令但读-改-写不是。volatile的*p 1编译成三条指令可能丢更新atomic的fetch_add编译成一条lock addl绝不丢。差异不在指令长相在标准保证的语义。这一集我们讲清 volatile / atomic / 内存序的机器真相以及数据竞争为什么是 UB。② 源码 vs 汇编对照__attribute__((noinline))intread_plain(int*p){return*p;}__attribute__((noinline))intread_volatile(volatileint*p){return*p;}__attribute__((noinline))intread_atomic(std::atomicint*p){returnp-load();}// 非原子的自增读-改-写分三步__attribute__((noinline))voidinc_volatile(volatileint*p){*p1;}// 原子的自增一条 lock 指令__attribute__((noinline))voidinc_atomic(std::atomicint*p){p-fetch_add(1);}三种读——指令完全一样read_plain(int*): read_volatile(int*): read_atomic(atomicint*): movl (%rcx), %eax movl (%rcx), %eax movl (%rcx), %eax ret ret retvolatile的自增 —— 三条指令非原子inc_volatile(int*): movl (%rcx), %eax ; ① 读 addl $1, %eax ; ② 改在寄存器里 movl %eax, (%rcx) ; ③ 写回 retatomic的自增 —— 一条指令原子inc_atomic(atomicint*): lock addl $1, (%rcx) ; 读-改-写一步到位且加锁 ret③ 为什么这么设计单次 load/store 在 x86-64 上对对齐的 int 天然原子硬件保证所以 volatile / 普通 / atomic 编译出来都是mov。差别不在这一条指令而在标准给编译器的约束volatile只禁止编译器合并、删除、重排对该变量的访问不提供跨线程原子性也不提供顺序保证。atomic memory_order提供跨线程的原子性与可见性保证编译器必须保证它不被拆开需要时自动加lock/fence。为什么 volatile 的*p 1会丢更新两个线程同时执行读 → 加 → 写可能都读到旧值、都写回 →丢一次更新。这是数据竞争在 C 里是未定义行为。数据竞争为什么是 UB编译器可以重排无依赖的访问CPU 会乱序执行。一旦你写出了跨线程竞争优化结果不可预测——看起来能跑只是运气E20 会展开。内存序seq_cst/acquire/release/relaxed规定这个原子操作对它前后的内存访问给出多强的顺序保证。x86 的 load/store 自带较强顺序store 带 release、load 带 acquire所以 fence 很少ARM 上才体现为不同的 fence 指令。正确做法多线程共享的计数器/标志用std::atomic需要持锁保护一片数据用mutex见 E16。volatile只适合单线程内阻止编译器优化如信号处理、与硬件交互。④ 深入一数据竞争丢更新到底是怎么发生的// 两个线程同时执行volatileintcounter0;// 或普通 intcounter1;// 读-改-写三步// 可能的交错丢一次更新// 线程A: movl counter → eax (读到 0)// 线程B: movl counter → eax (读到 0)// 线程A: addl 1 → eax (eax1)// 线程B: addl 1 → eax (eax1)// 线程A: movl eax → counter (counter1)// 线程B: movl eax → counter (counter1) ← 两次自增结果却是 1丢了一次这就是读-改-写竞争的最典型后果换成atomiclock addl $1, counter一条指令不可分割绝不丢换成mutex两线程串行执行整个counter 1也不丢。所以volatile 对多线程没用的确切含义它不解决读-改-写的原子性问题而这正是并发计数最需要的。⑤ 深入二内存序的四档与它们保证什么std::memory_order四档从强到弱档位保证机器形态x86seq_cst默认全局一致顺序load/store 普通 mov 需要时 fenceacquire/release配对同步发布-订阅x86 store 自带 release、load 自带 acquire通常零指令relaxed只保证单操作原子普通 movRMW 仍 lockconsume少用依赖链同步基本等同 relaxed 实现关键认识对RMWxadd/cmpxchg/exchange四档在 x86 上汇编一样都要 lock——E16 已见对load/storex86 是强内存模型普通 mov 已够大部分场景ARM 是弱内存模型relaxed 少 fence、seq_cst 多 fence跨平台写代码用最弱的满足正确性的档relaxed 够就 relaxed让各平台发挥但默认 seq_cst最安全。⑥ 常见误区误区 1“volatile 能做线程同步”不能——它只阻止编译器优化访问不提供原子性/顺序。误区 2“atomic 的 load/store 比普通访问慢”x86 上单次 load/store 就是普通 mov几乎零额外成本只有 RMW 有 lock。误区 3“relaxed 一定更快”x86 上对 RMW 没差别ARM 上 load/store 有差别。别无脑 relaxed默认 seq_cst。误区 4“数据竞争只会得到错误值”竞争是 UB——可能错误值、可能崩、可能优化器做出任何事。误区 5“多线程读同一变量不用同步”只要有一个线程写、其他线程读同一非原子变量就是竞争。即使只读不写也要求要么全只读、要么有同步。误区 6“volatile能保证读取的是最新值”不能。volatile不提供跨线程可见性/顺序保证读最新值需要原子 内存序或锁。误区 7“数据竞争在 release 下才出现”数据竞争在任何优化级别都是 UB只是-O0下碰巧不容易触发。别用release 没事来安慰自己——那是运气不是正确性。误区 8“std::atomic就是volatile的强化版”方向不同。volatile管编译器别优化这次访问atomic管跨线程的原子性 顺序 可见性。std::atomic内部通常同时做了 volatile 该做的事阻止优化但反过来 volatile 一点原子性都没有。误区 9“只要用 atomic程序就线程安全”原子只保证单个原子操作和按内存序的可见性你写的复合逻辑读-判-写多步仍需设计如 CAS 循环或锁。原子是原语不是万能安全罩。误区 10“volatile能防止编译器优化掉自增”它防止合并/删除对该变量的访问但*p 1仍是读-改-写三条本集汇编——优化不掉的是访问不是原子性。误区 11“memory_order_relaxed没有任何意义”它在不需要顺序、只要原子的场景有用如统计计数、无释放依赖的计数且 ARM 上更快。只是别在需要发布-订阅时用它。⑦ 实战启示别用volatile做线程同步它不是原子、不给顺序保证。共享标志用std::atomicbool 合适的memory_order。数据竞争是 UB不是可能错编译器优化 CPU 乱序可能让结果彻底崩坏。用 TSan 等工具定期检测。mutex不是洪水猛兽临界区短时正确同步的开销远小于错误同步导致的 bug 修复成本。发布-订阅模式一个线程写、另一个线程读用 atomicacquire/release或mutex就够不要为了看起来快去赌无锁正确性。用 TSanThreadSanitizer-fsanitizethread运行时检测数据竞争是发现这类 bug 最有效的手段E20 会展开 sanitizer 家族。⑧ 扩展专题一发布-订阅Publish-Subscribe模式的完整机器码经典发布-订阅std::atomicboolready{false};intdata0;// 线程 1发布data42;// 普通写ready.store(true,std::memory_order_release);// 发布// 线程 2订阅while(!ready.load(std::memory_order_acquire)){}// 等 readyuse(data);// 普通读一定看到 42release store保证它之前的写data42在 ready 可见前完成acquire load保证它之后的读use(data)在 ready 可见后开始机器码x86 上release store常是普通movx86 store 天然 releaseacquire load是普通mov——零额外指令但语义正确ARM 上才插 fence。这就是发布-订阅的现代写法用 acquire/release 配对比 mutex 轻、比 relaxed 正确。理解了它你就掌握了内存序 90% 的实际用途。⑨ 扩展专题二x86 vs ARM 内存模型——为什么看起来一样又不一样x86强模型普通 load/store 顺序性强store 天然带 release、load 天然带 acquire所以 acquire/release 通常零 fence硬件已经够了relaxed 与 seq_cst 差异小。ARM弱模型允许更多重排relaxed 真的松seq_cst / acquire / release 需要显式dmb数据内存屏障等 fence 指令同一 C 代码在 ARM 上 relaxed 快、seq_cst 慢——差异真实存在。工程结论写跨平台并发代码时用满足正确性最弱的内存序在 x86 上测试看起来都对不代表 ARM 上对——内存模型是 ABI 之外的另一层可移植性要求E23 会再谈。⑩ 扩展 FAQQstd::atomic的默认 memory_order 是什么Aseq_cst最强。最安全但跨平台可能最慢ARM 上 fence 多。Qstd::mutex和 atomic 的可见性谁强A都提供获取/释放级可见性mutex 的 lock/unlock 等价 acquire/release。mutex 还提供互斥串行atomic 只保证单个操作原子。Qvolatile还有用吗A有——信号处理中的标志、内存映射 I/O硬件寄存器、阻止编译器把看似重复的访问优化掉。用途是阻止优化不是线程安全。Q怎么检测数据竞争ATSan-fsanitizethread、Helgrindvalgrind。CI 里定期跑比靠 review 可靠。Qstd::memory_order_consume该用吗A几乎不用。它依赖数据依赖链同步编译器难以精确实现实际常按 relaxed 处理。用 acquire/release 更稳。⑪ 扩展实验三种读反汇编g -O2 -S E17_volatile.cpp确认三条movl一样本集汇编。丢更新演示两线程各对volatile int自增 100 万次最终值 200 万丢更新换成atomic后 200 万。acquire/release 反汇编发布-订阅代码-O2 -S看 x86 上是否零 fence。TSan 检测-fsanitizethread跑竞争代码观察运行时报告。relaxed vs seq_cst非 RMW 的 load/store 循环ARM 交叉编译clang--targetaarch64对比 fence 指令差异。⑬ 扩展专题三fence 指令到底长什么样当编译器需要在普通代码里插入内存屏障时会用 fence 指令x86mfence全屏障、lfenceload 屏障、sfencestore 屏障——还有lock前缀指令自带屏障效果E16 讲过ARMdmb ish数据内存屏障内部共享域、dsb更重、ldar/stlr单条 load-acquire/store-release 指令。为什么 x86 上 relaxed 和 seq_cst 差不多x86 硬件本身顺序性强编译器很少需要mfence。但别把这当通用规律——ARM 上差异明显跨平台代码必须按内存模型想。fence 的成本屏障指令可能阻塞流水线/内存访问比普通 mov 贵。所以内存序越弱越快在弱模型上真实成立——这也是能用 relaxed 就用的机器理由。⑭ 扩展专题四单生产者-单消费者SPSC队列的汇编SPSC 无锁队列是内存序的经典应用两个原子头、尾// 生产者写数据后 release 更新尾buf[tail]item;// 普通写tail.store((tail1)%N,std::memory_order_release);// 消费者acquire 读头再读数据while(head.load(std::memory_order_acquire)tail){}// 空转等itembuf[head];// 普通读一定看到新数据生产者 release store 尾 → 消费者 acquire load 尾形成发布-订阅配对机器码x86 上 buffer 写/读是普通 mov两个 atomic 也是普通 movstore 自带 release——整条 SPSC 队列在 x86 上几乎零 fence这就是无锁但正确的样板用内存序代替锁在强模型上免费。启示现代 C 的无锁不是没有同步而是用更便宜的内存序同步。理解 acquire/release 配对是写无锁代码的第一课。⑮ 扩展 FAQ第二轮Qstd::atomic的is_lock_free()什么意思A该类型是否用真正无锁的硬件指令实现是 → 原子操作无内部锁否 → 内部可能用锁模拟。查它可确认无锁承诺。Q为什么seq_cst在 ARM 上慢A它要求全局一致顺序ARM 弱模型需要多个 fence/特殊指令才能模拟比 relaxed零 fence慢。Qvolatileatomic能混用吗A别混用保护同一变量——语义混乱、难维护。要么全 atomic要么全锁。Q内存序会影响编译器优化吗A会。atomic的操作是优化边界编译器不能随意重排/删除relaxed给优化器更多自由可能更快。Qstd::atomic_thread_fence和 atomic 操作的 fence 区别A前者是独立 fence在任意位置插屏障后者是操作附带序。独立 fence 更灵活但更容易写错优先用带序的原子操作。Qacquire/release能乱配吗Arelease 必须配 acquire或更强才有发布-订阅同步relaxed 配 release 无同步效果。配对错了代码看起来对但语义没保证。Q多线程共享只读数据需要同步吗A初始化后只读所有线程都不写→ 不需要同步但一个线程写、其他线程读→ 需要发布-订阅或锁。写者存在就需同步。⑯ 扩展实验第二轮mfence 观察手动std::atomic_thread_fence(std::memory_order_seq_cst)反汇编找mfence。ARM 交叉编译clang--targetaarch64-none-elf -O2 -S编译 acquire/release 代码找dmb/ldar/stlr与 x86 的差异E22 会全面对比 x86 vs ARM。SPSC 队列实现单生产者单消费者-O2 -S确认 x86 上零 fence。relaxed 计数器多线程 relaxed 计数 vs seq_cst 计数x86 上对比应该几乎相同验证强模型。TSan 实战故意写一个竞争 用-fsanitizethread抓出来熟悉 sanitizer 工作流。⑱ 扩展专题五为什么看起来能跑的数据竞争最危险数据竞争是 UB但它的危险在于**碰巧能跑掩盖了问题**优化级别不同行为不同-O0时编译器不做激进重排竞争代码可能正常-O2下被重排/缓存后突然崩硬件不同行为不同x86 强模型可能没出过问题移植到 ARM 弱模型就炸时序不同行为不同单核/低负载时竞争窗口小多核/高负载时才触发。// 危险示例非原子标志 普通数据boolstopfalse;// 不是 atomic// 线程1: while (!stop) work(); // 可能被优化成读一次寄存器永不退出// 线程2: stop true; // 写它但线程1可能看不见编译器可能把while (!stop)优化成只读一次因为没看到 stop 被改的同步点——结果线程 2 改了也白改这不是罕见 bug是 UB 在优化下的必然结果。教训共享标志必须是std::atomic或受锁保护。别赌反正只是 bool——编译器优化不会跟你讲情面。⑲ 扩展专题六std::atomic的 load/store 与优化边界为什么atomic能防止编译器读一次就缓存因为标准规定原子操作是优化边界编译器不能合并/删除/重排原子操作除非能证明等价编译器不能把原子 load 提升出循环否则可能读不到别的线程的更新编译器不能把普通访问跨过原子操作重排如果违反内存序。对比volatile它只约束对该变量的访问atomic约束对该操作及其周围内存访问的顺序。这正是两者在多线程上本质不同的原因——volatile 管自己atomic 管自己和别人的关系。⑳ 扩展专题七内存序与可见性的直觉模型很多教程用内存序 可见性顺序来解释但正确的心智模型更微妙每个原子操作形成一个同步点release 写发布了它之前的所有写acquire 读接收了这些写两个线程之间只有当线程 A 的 release 写和线程 B 对同一位置的 acquire 读配对上A 之前的写才对 B 可见没有配对A 写的数据对 B “不保证可见”——即使 B 也能读到那个普通变量的值可能读到旧值。std::atomicboolr{false};intx0;// A: x 42; r.store(true, release);// B: while (!r.load(acquire)) {}; use(x); // 保证看到 42有配对 →use(x)一定看到 42即使 x 是非原子普通变量无配对 →use(x)可能读到 0。一句话release/acquire 配对是传递数据的通道没有配对数据传递不保证。这个直觉比内存序栅栏更有用。㉑ 扩展 FAQ第四轮Qstd::atomicint初始化和赋值有什么坑Astd::atomicint a 5;用ATOMIC_VAR_INIT或花括号初始化a{5}别用拷贝赋值a b原子不可拷贝用store/exchange。Qstd::atomic能做序列化吗A单原子操作原子多操作组合不原子a 1; b 1之间可能被穿插。要原子组合用锁或事务性原语。Q为什么seq_cst是默认A它最符合直觉全局一致顺序多数代码用它正确性最容易推理。性能敏感处再逐处放宽。Qvolatile能用于信号处理吗A能volatile sig_atomic_t是标准允许的异步信号安全交流方式——因为那是同一线程内阻止优化 异步信号场景不是多线程数据传递。Q内存模型是 C 特有的吗A不是。Java、Rust、Go 各有内存模型。C 的memory_order是最底层、最显式的一套。Q为什么说多线程 bug 很难重现A竞争/乱序依赖调度时序、核数、缓存状态——这些每次运行都不同。所以要用 TSan 等工具系统性检测而不是靠多跑几遍。Qstd::atomic的compare_exchange是读-改-写原子吗A是lock cmpxchgE16 讲过。它常用于基于旧值算新值的无锁更新——一次失败重试循环。㉒ 扩展实验第四轮无配对验证去掉 acquire/release 配对的发布-订阅x86 上可能碰巧对、ARM 上可能错——交叉编译对比。原子赋值错误std::atomicint b a;拷贝赋值编译报错理解原子不可拷贝。TSan 全绿把正确代码跑 TSan确认零报告把volatile版跑 TSan确认报告竞争。多操作穿插两线程各自a1;b1观察中间状态b 变了 a 没变验证组合不原子。seq_cst vs relaxed 实际差异x86 上反汇编对比 load/store 循环应几乎相同写进笔记。㉓ 悬念原子 内存序管的是多线程同时访问同一块内存。还有一种单线程内就能交出控制权的机制——协程。