直接上干货。这篇内容本来是给我组里新来的同事做培训用的后来觉得整理成文章分享出来更有价值。C内存模型这东西刚接触会觉得玄乎像是在研究什么哲学问题实际上它就是一套关于“约定”的规则搞清楚了并发编程里的很多坑就能提前绕开。1. 为什么要折腾出一个“内存模型”很多人写多线程代码第一反应是加锁。锁能保证临界区只有一个线程进入这没问题。但锁背后的东西比如原子操作、无锁数据结构、读写共享标志位这些才是真正依赖内存模型的地方。1.1 没有规则的时候有多痛在C11标准之前C没有真正意义上的多线程内存模型编译器做优化的时候只假设程序是单线程跑的。这就带来一个很实际的问题你写了一个看起来没问题的双线程程序比如一个线程改标志位另一个线程轮询这个标志位在O2优化级别下可能根本跑不出预期效果。编译器会认为循环里读的那个变量没人改直接把这个读操作提到循环外面导致你等半天等不到标志位变化。这还只是编译器层面的重排。到了CPU层面现代处理器为了压榨性能指令执行顺序和汇编写的顺序可能完全不一样加上多核架构下每个核心有自己的缓存一个核写了数据另一个核不一定立刻能看到。如果没有一套规则约束编译器、CPU、缓存这些层级的操作用一句大白话讲多线程就是混沌状态谁也不知道什么时候能看到什么数据。1.2 内存模型到底规定了什么C11引入了完整的在线程抽象和原子库同时也给出了内存模型的正式定义。核心就两条定义了线程、信号处理函数、主线程等实体之间的操作关系。规定了“数据竞争”是未定义行为两个线程同时访问同一内存位置至少有一个是写操作且没有同步关系。后一条尤其关键。很多人写并发代码出奇奇怪怪的bug最后定位到同一个共享变量上本质上就是数据竞争导致的未定义行为。内存模型要解决的核心问题就是定义清楚什么样的操作顺序是合法的什么样的同步手段可以让不同线程之间建立可见性关系。2. 原子操作与六种内存序的内在逻辑C11标准库里的std::atomic是理解内存模型的最佳窗口。原子操作保证了读改写是一条不可分割的操作而内存序参数则决定了这个操作对其他线程的可见性约束有多强。2.1 为什么内存序参数这么重要先看最常用的写法。很多人写共享计数器直接就是store和load用的是默认参数std::memory_order_seq_cst顺序一致。这样做有它的道理也是最不容易出错的。但代价是性能受限尤其在一些弱内存序的处理器架构上全面顺序一致往往会带来额外开销。内存序按约束强度从小到大排列relaxed、consume、acquire、release、seq_cst分为acq_rel与seq_cst两个状态。其中最常用的是四种relaxed、acquire、release和seq_cst。这六种内存序本质上是在回答一个问题我这个原子操作写了一个值其他线程读到这个值时哪些发生在写操作之前的事情也一并保证可见这个表述有点绕建议记住一个生活化类比你往公告栏贴了一张通知release贴完通知之后你才把自己的实验结果放在通知下面那么所有看到这张通知的人acquire也一定能看到你放在下面的实验结果。这就是release和acquire之间建立的“配对”关系。2.2 用x86和ARM的差异理解内存序不同硬件对内存序的支持力度天差地别。x86架构是强内存序模型普通store操作天然带有release语义普通load操作天然带有acquire语义所以x86上的无锁代码往往“看起来能跑”。而ARM和PowerPC这类弱内存序架构CPU可以自由重排读写指令所以同样的代码在x86上测得好好的交叉编译到ARM上就出现诡异的数据出错。我自己踩过这个坑。当时写一个生产者消费者的无锁队列在x86开发机上压力测试一整天都没问题部署到某ARM平台上第一天就偶发崩溃。后来用TSan线程消毒器跑了一遍立刻就暴露了缺少acquire/release配对的问题。从那之后我养成了一个习惯新写的无锁代码必须在ARM或基于ARM的云实例上跑一轮测试否则不放心。3. 正确的同步姿势从标志位到无锁结构理解了内存序的理论还是得看实际代码。下面这一段是我工作中经常用来跟同事演示的经典场景。3.1 一个生产者消费者的正确写法假设有一个生产者线程负责计算结果消费者线程负责读取打印两者通过一个原子标志位通信。std::vectorint data; std::atomicbool ready{false}; void producer() { data.push_back(42); // 普通写操作 data.push_back(84); ready.store(true, std::memory_order_release); // 发布数据 } void consumer() { while (!ready.load(std::memory_order_acquire)) { // 等待 } // 此时读取 data 是安全的吗? std::cout data[0] , data[1] \n; }这里的关键在于ready.store用了releaseready.load用了acquire。Release操作保证了在它之前的所有普通写操作不会被重排到它之后所以当消费者通过acquire看到ready为true时生产者往data里写的内容也一定对消费者可见。反过来如果这里用的是relaxed这个程序就是未定义行为。数据竞争直接就存在了虽然大多数时候可能碰巧能跑对但编译器一旦在某种优化路径下选择了不同的指令调度结果就可能完全错乱。这就是为什么我一直强调共享变量传递数据必须用release/acquire配对而不是想当然地认为“我加了原子变量就安全了”。3.2 seq_cst什么时候是必要的seq_cst是最强的内存序也被称为“全序一致”它要求所有线程观察到的原子操作顺序完全一致。这个特性对于某些算法是必要的前提比如要求程序在所有线程视角下都看到同一个全局事件顺序的算法。判断自己是否真的需要seq_cst有个简单标准如果去掉seq_cst你的算法还能正确工作吗回答不上来就先用seq_cst先把正确性保证住等性能真正出现瓶颈了再考虑降低约束。这个思路在团队里我反复跟人强调性能是后置的正确性是前置的不要为了那点性能提升把正确性的基础打歪了。注意seq_cst在x86平台几乎不产生额外开销因为x86本身就是强序架构。但在ARM这类弱序平台seq_cst的实现往往需要显式的内存屏障指令成本要高出不少。3.3 relaxed用在哪类场景relaxed并不是“垃圾”选项它适合完全不关心顺序、只关心原子性的场景。最典型的是计数器std::atomicint counter{0}; void worker() { counter.fetch_add(1, std::memory_order_relaxed); }这里只要保证计数不会丢、不会错不需要任何顺序约束relaxed是最自然的选择也是性能最好的选择。另一个典型场景是类似生成唯一ID的递增操作同样只需要原子性不需要和别的变量建立可见性关系。4. volatile与内存模型的边界很多老C程序员是从C语言时代过来的习惯了用volatile做多线程同步。这个习惯在C11之后应该彻底抛弃。原因很简单volatile在C标准里的语义是“告诉编译器不要优化掉对该变量的访问”它并不提供任何线程间的顺序保证和原子性保证。我用一句话概括这两者的区别volatile管的是编译器层面的“别给我缓存这个读”std::atomic管的是硬件和编译器层面“我的读写要满足一致性规则”。前者是在和编译器对话后者是在和整个系统对话。4.1 volatile真正擅长的领域volatile在现代C里最主要的用途是操作内存映射的硬件寄存器。比如嵌入式开发中读某个状态寄存器你希望每次都真实地读取硬件返回值而不是编译器把上次的结果缓存住这时候用volatile是合适的。还有一类场景是在信号处理器signal handler里读写标志位。C标准明确说信号处理器可以访问volatile sig_atomic_t类型的变量。这种场景也是volatile发挥作用的正确位置。4.2 一个让我印象深刻的线上问题之前维护过一个跨平台兼容层某模块的退出标志位用了volatile bool在x86上压测、线上跑都没事后来移植到新平台后偶尔出现退出逻辑迟迟不响应的现象。当时我排查了半天最后发现那段代码被编译成了循环内每次重新读取内存而不是像x86那样直接命中寄存器缓存——恰恰是volatile的语义并没有阻止所有层的重排编译器只是保证“读操作不被消除”但并没有保证“线程间的可见时序”。后来改成std::atomicbool配合acquire/release之后问题彻底消失。这件事给我的教训是不要用“反正x86上能跑”来安慰自己跨平台就要按标准来做。5. 想少踩坑就记住这几条实践原则从标准理解到实践有一段不小的距离。下面这几条是我在代码审查里反复强调的每一条背后都对应过真实的线上事故。5.1 标准库提供的比自定义的好优先使用std::atomic、std::mutex、std::condition_variable这些标准组件。标准库没有额外魔法但它把正确性沉淀在库的实现层面且经过了整个社区的测试和验证。所谓“自己用手写原子变量攒一个无锁结构”不是不能做但要清楚代价是误用内存序带来的难以复现的bug调试成本极高。我也见过团队为了炫技把一个简单的并发计数器改成了无锁实现还引入了一个自定义内存序组合最后压测时数据对不上折腾了三天。事后看这个场景用普通互斥锁的性能差异根本可以忽略。所以先用简单方案跑通业务再在性能分析数据指引下做优化。5.2 工具是排查并发问题的好帮手写的代码不出并发问题是不可能的出了也别慌有专门的工具可以用来定位。ThreadSanitizerTSan是排查数据竞争的利器编译时加上-fsanitizethread就能在运行时精准报告数据竞争地址和调用栈。这比你自己一行行看代码高效得多。另外-fsanitizeundefined也可以配合使用排查未定义行为相关的问题。我现在的习惯是所有涉及并发的提交测试阶段全部开TSan跑一轮过了这关才进入常规测试。5.3 代码审查环节的检查清单这里我可以提供一个检查清单都是日常审查并发代码时逐条过的共享变量是否都被声明为std::atomic或者总是受同一个互斥锁保护是否出现过把普通变量直接在线程间传递、只靠“感觉”来保证可见性的写法每个release写操作是否有对应的acquire读操作形成配对代码注释里是否清楚解释了内存序选择的原因有没有为了性能直接拍脑袋用relaxed的地方给出过依据吗如果这些问题在任何一条上回答得模棱两可那大概率这里就是藏雷的地方。5.4 理解消息传递的顺序性最后再展开讲一个比较隐蔽的点。假设三个线程之间的消息传递是“链式的”线程A store一个值并release线程B acquire读取后再release写另一个值线程C acquire读取B的值。这个场景下A和C之间看似不直接关联但因为B的release依赖于A的数据C通过acquire读到了B的数据间接地也保证了A的数据对C可见。这种链式传递的可见性规则是内存模型的核心能力之一很多复杂的无锁算法正是建立在这个机制上。举个例子你写了一个无锁的栈实现入栈操作把新节点通过CAS比较交换挂到栈顶。这里的compare_exchange_weak/strong通常使用memory_order_release而出栈操作使用memory_order_acquire的CAS或者load就是为了形成这种链式可见性一旦某个线程成功把节点挂到栈顶之前对该节点数据的写入就对将来弹出该节点的线程可见。6. 聊聊编译器重排和CPU乱序的实际影响前面提到了很多次“重排”那它到底发生在哪里6.1 编译器层面的指令调度现代编译器在生成汇编时会根据优化等级做指令重排。比如x 1; flag true;在未指定内存序的情况下编译器完全可能让flag true先执行。原因在于在没有多线程约束的前提下x和flag之间不存在数据依赖编译器认为交换次序不改变程序单线程执行语义。这个“我们认为无关紧要”的假设恰恰就是内存模型要纠正的东西。解决办法要么让flag成为std::atomicbool并用release语义写要么用std::atomic_thread_fence显式加一个栅栏。6.2 CPU乱序执行就算编译器没有重排CPU拿到指令后也可能乱序执行。当代CPU内部有复杂的执行单元只要不破坏单核语义指令顺序是可以动态调整的。多核之间还涉及缓存一致性协议比如MESI核A对某地址的写并不会立刻同步到核B的缓存里B要经过缓存一致性协议后才能看到这个改动。这也是为什么内存序里的acquire/release在低层往往对应着特定的缓存一致性操作或屏障指令。你可以把acquire/release对视作一种“同步点”硬件在这些同步点耗时保证顺序其余时间则放任乱序来换取性能。做个小结内存模型是编译器、CPU、缓存共同遵守的一份协议。作为开发者我们通过内存序参数告诉编译器“这里我需要严格的可见性约束”编译器再在生成汇编时插入必要的指令来让CPU遵守这个约定。7. 面对性能调优的正确姿势有经验的朋友可能会说内存序太强会影响性能那怎么平衡正确性和性能呢我的建议分三层第一层先用seq_cst把正确性跑通确保逻辑没有问题。第二层用性能分析工具perf、vtune或者自家平台的profiler定位到真正有压力的原子操作和热点代码。不要看代码猜性能实测数据才有说服力。第三层针对确认为瓶颈的操作考虑降级内存序到acquire/release甚至relaxed。每降一级都要配合强压力测试和TSan用数据证明正确性没有被破坏。有一类程序比如高频交易系统或者某些实时音视频处理对延迟极度敏感这时候每一两个内存屏障指令都弥足珍贵。但即便是这类场景也是测出来的瓶颈才值得优化。过早优化是万恶之源这句话放在内存序上特别成立。最后我再真诚建议一次遇到并发bug优先怀疑自己的内存序使用而不是怀疑编译器和CPU尤其不要用“x86上重试了几千次都没问题”来安慰自己。跨架构、跨编译器、跨优化等级标准保证才是唯一靠得住的依据。写并发代码多花十分钟想清楚可见性未来就能少花十个小时排查线上事故。
