写过 C 多线程程序的人大概率都经历过类似的一幕起了一个后台线程让它循环跑任务主线程想让它停止时就把一个 bool 类型的停止标志置为 true。程序在 Debug 下跑得好好的到了 Release 下却像没听见一样任务线程怎么都不退出更离谱的是有时一切正常有时延迟好几秒才停下来。问题就出在那个普通 bool 上。这就要用到今天的主角 std::atomic_bool——C11 标准提供的并发安全布尔类型本质是 std::atomic 的别名。这篇文章我会从一个真实场景切入把它的接口、内存序、实现原理、常见用法和踩坑经验都梳理一遍。适合刚入门并发编程、想搞清楚原子变量到底在做什么的 C 开发者也适合写过一点多线程但始终对 memory_order 一知半解的朋友。1. 多线程读 bool 为什么会失控先理解数据竞争的真相1.1 一段看似正常的代码为什么到 Release 就失灵很多人在刚接触多线程时都写过类似的代码bool g_stop false; void worker() { while (!g_stop) { // 处理任务... } } // 主线程 g_stop true;单看逻辑这个循环“应该”能退出。可真实世界里它往往不退出尤其是在打开编译器优化比如 -O2之后。原因其实很简单普通变量 g_stop 的读写没有任何并发语义编译器在优化时只需要保证它在“单线程视角”下行为正确。它发现 while (!g_stop) 循环里 g_stop 没有被修改于是非常合理地把它从内存加载到寄存器然后把这个循环优化成“读寄存器里那个恒定的值”。寄存器里的值永远是 false于是循环就彻底变成死循环外面再怎么改 g_stop 都没用。这不是编译器故意使坏而是 C 标准赋予它的权力在没有同步机制的情况下它默认所有代码都在同一个线程里执行。1.2 数据竞争是未定义行为不是“按理说能看见”有人会反驳“那我清掉 L1 缓存之后是不是就能看到最新值了”抱歉问题远远没有这么简单。多个线程同时访问同一个非原子变量只要其中至少一个操作是写操作这个代码就构成了数据竞争data race。在 C11 标准之下数据竞争是未定义行为。未定义行为意味着编译器可以做任何事它可以假设这种状况永远不会发生然后按照这个假设去优化代码它可以改变读写顺序它可以删除它认为“多余”的访问甚至可能出现你完全无法解释的执行结果。再叠加现代 CPU 的硬件行为指令乱序执行、写缓冲、多核之间的缓存一致性同步延迟都会让你对“这个变量刚被改过”的判断失效。数据竞争这个问题不是单纯“值同步慢”的问题而是程序整体行为都可能变得不可预测。1.3 atomic_bool 到底改变了什么std::atomic_bool 就是为了解决这类并发读写问题而生的。它来自atomic头文件是std::atomicbool的别名。它的价值体现在两个层面首先是原子性。对它的读、写、读改写操作在硬件层面是一条不可分割的指令不会被其他线程插入到一半打断。其次是内存序语义。它允许你指定操作之间的顺序约束也就是后面我们会详细聊的 memory_order。有了这个编译器不能随便把它当成普通 bool 去优化硬件也不能随意重排它周围的指令。用起来也一样不复杂std::atomic_bool g_stop{false}; void worker() { while (!g_stop.load()) { // 处理任务... } } g_stop.store(true);就这么小小的改动之前那个“停不下来”的问题就被解决了。这又引出一个问题store 和 load 为什么默认就能保证行为正确这就必须说清楚 C 内存模型和默认的顺序一致性。2. 接口全家桶函数不多个个有讲究2.1 store 与 load最基础的读写姿势std::atomic_bool 的核心接口其实非常简单常用的是 store 和 load。store 负责写入新值load 负责读取当前值。它们都接受一个额外的内存序参数默认是std::memory_order_seq_cst也就是顺序一致性。std::atomic_bool running{true}; running.store(false); // 写入 false bool value running.load(); // 读取当前值不少同学会直接写running false或if (running)因为 std::atomic_bool 重载了赋值和 bool 转换操作符。但我在项目里更推荐显式调用 store 和 load理由是一眼就能看出这里在操作一个原子变量代码评审时不容易被忽略。顺序一致性的意思是所有关于该原子变量的操作在全局上存在一个唯一、一致的总顺序而且这个顺序和代码顺序保持一致。通俗地说它给了你最严格的可见性保证“我写完了你立刻能看到最新值。”2.2 exchange一条指令完成“读旧值 写新值”store 只能写到目前为止的值如果想要“读出旧值并同时写入新值”就需要 before exchange。它相当于一条原子化的 RMWRead-Modify-Write操作std::atomic_bool flag{false}; bool old flag.exchange(true);这个操作在执行时不会被其他线程的 RMW 操作穿插因此非常适合做互斥逻辑。最简单的自旋锁就可以基于它实现如果 exchange 返回 false说明锁之前的持有者是 false也就是没人占用当前线程成功拿到锁如果返回 true说明锁已经被别人持有继续循环等待。这类“读旧写新”的操作在实现无锁数据结构时特别常见。Atomic_bool 虽然只是个布尔类型但这一招已经能撑起不少并发场景。2.3 compare_exchange条件更新才叫“高级”compare_exchange 是原子库里最复杂的操作std::atomic_bool 同样提供了而且分成 weak 和 strong 两个版本。std::atomic_bool inited{false}; bool expected false; bool desired true; bool success inited.compare_exchange_strong(expected, desired);它的语义是如果当前值和 expected 相等就把当前值改成 desired并返回 true如果不等就把 expected 修改成当前值并返回 false。注意 expected 是一个引用失败时它会被更新。weak 和 strong 的区别在于weak 即使在当前值确实等于 expected 的情况下也可能因为平台原因发生“伪失败”spurious failure返回 false。strong 则不会。那么为什么还要有 weak因为在部分硬件上 weak 可能编译出更高效的指令。实际上compare_exchange_weak 通常被用在循环里配合重试伪失败导致的失败不过就是多循环一次而已性能影响很小。2.4 别忘了atomic_bool 没有 fetch_add也没有复合赋值原子类型里有 fetch_add、fetch_or、fetch_xor 这一族操作但 std::atomic_bool 一个都没有。原因也很直白bool 类型本身不参与算术运算和位运算原子库自然不提供fetch_add(true)这种荒诞接口。这就带来一个容易踩的坑如果你想用一个二进制位节省空间或者想对标志位做flag | something这种原子逻辑atomic_bool 干不了这个活得换成std::atomicint、std::atomicuint32_t才行。当然也有同学把 atomic_bool 和 atomic_flag 搞混后面我会专门讲两者的区别。3. 内存序理解 atomic_bool 的第二个门槛3.1 六种内存序速查表如果说原子操作解决的是“这条语句会不会被打断”那么内存序解决的是“这条语句周围的指令会不会被悄悄重排”。std::atomic_bool 的使用几乎绕不开下面这张表。内存序说明直观理解memory_order_relaxed只保证原子操作本身不可拆分不提供顺序约束只保证我这一条语句不被打断其他顺序你们随意memory_order_consume依赖序围绕数据依赖做同步标准里存在但实际移植性差一般不建议用memory_order_acquire用于读操作禁止当前读之后的读写越过本操作我在“拿锁”“看别人发布的数据”时用它memory_order_release用于写操作禁止当前写之前的读写越过本操作我在“释放锁”“发布数据”时用它memory_order_acq_rel读改写操作同时带 acquire 与 release我既要读旧值又要发布新值时用它memory_order_seq_cst最强约束所有 seq_cst 操作存在一致的全序默认值最安全但成本也最高在 x86 平台上acquire load 和 release store 通常对应普通的 mov 指令因为 x86 硬件本身就带了较强的顺序保证但 seq_cst 在 store 时往往需要额外的屏障指令。在 ARM 这类弱内存模型平台上acquire/release 也可能需要显式的内存屏障指令。所以不要以为 atomic_bool 一定零开销跨平台移植时要心里有数。3.2 一个必须掌握的 release-acquire 传递模型很多文章讲内存序喜欢堆术语但我觉得最直观的用法是“release 发布数据acquire 接收数据”。看一个经典例子int data 0; std::atomic_bool ready{false}; // 生产者线程 data 42; ready.store(true, std::memory_order_release); // 消费者线程 while (!ready.load(std::memory_order_acquire)) { // 等待就绪... } use(data); // 这里能保证 data 42为什么data明明只是一个普通 int却一定能读到 42因为 release store 与 acquire load 形成了一种“同步关系”。生产者线程在 release 写之前对内存做的所有修改消费者线程在 acquire 读之后都能看到。这个关系是 C 内存模型承诺的不只针对 atomic_bool也覆盖它之前/之后的普通内存访问。这是我最推荐初学者理解 atomic_bool 的方式不要只把它当成一个“状态开关”它还能当一个“数据接力棒”。只有持有这个接力棒数据才能安全跨线程传递。3.3 实际选型默认 seq_cst能优化再降级在真实项目里我见过不少人一上来就追求性能把每个原子操作都改成 relaxed。这种做法我觉得风险大于收益。原因很简单内存序一旦降级涉及的是整个程序正确性而不是某一行代码的效率。要分析清楚 relaxed 是否安全需要你把所有线程的读写路径都过一遍这对团队里每个人都是负担。我的习惯是第一版先用默认的 seq_cst保证逻辑正确等跑完性能测试证明原子操作确实是瓶颈再逐行去分析能否改用 acquire、release 甚至 relaxed并且每改一处都配注释说明理由。绝大多数场景下seq_cst 的性能损失远没有想象中那么大而内存序写错导致的排查成本却高得惊人。4. 实战自旋锁、线程池停止、一次性初始化4.1 自旋锁最简 test-and-set 锁利用 exchange 的“读旧写新”特性可以写出一个极简自旋锁class SpinLock { public: void lock() { while (flag_.exchange(true, std::memory_order_acquire)) { // 锁被占用自旋等待 std::this_thread::yield(); } } void unlock() { flag_.store(false, std::memory_order_release); } private: std::atomic_bool flag_{false}; };lock 里第一次 exchange 如果返回 false说明锁之前是空闲的本线程可以进入临界区。后续线程的 exchange 会持续返回 true于是它们在循环里空转等待。release 与 acquire 配对确保了临界区里的普通内存操作在锁释放之后对其他线程可见。这个自旋锁的优点是实现短小、不依赖操作系统缺点是只适合临界区极短的场景。如果临界区里有耗时操作大量线程空转会把 CPU 吃满性能反而会比 std::mutex 差很多。实践中我还会在自旋循环里加入__builtin_ia32_pause之类的 CPU 暂停指令x86或yield能缓解部分缓存一致性带来的总线压力。4.2 线程池关停标志atomic_bool 的最佳应用场景线程池关闭是最常见的 atomic_bool 使用场景。线程池里的 worker 线程反复取任务执行主线程想要优雅地关闭它不需要暴力 terminate只需要把一个停止标志置为 true让 worker 在下一次循环判断时退出。class ThreadPool { public: void stop() { stop_.store(true, std::memory_order_relaxed); for (std::thread t : workers_) { if (t.joinable()) { t.join(); } } } private: std::vectorstd::thread workers_; std::atomic_bool stop_{false}; }; // worker 线程内部 while (!stop_.load(std::memory_order_relaxed)) { // 从任务队列取任务并执行 }这里我把内存序写成了 relaxed可能有人会质疑。对于纯停止标志如果 worker 线程不需要在退出后读取主线程发布的额外数据relaxed 就足够了因为我们需要保证的只是“这个原子变量值本身不会出现撕裂”。但如果 worker 在退出前需要读取主线程在此之前发布的配置信息那就必须换成 acquire/release 或 seq_cst否则存在数据竞争风险。所以我的建议是除非你能明确说出“这里不需要传递其他数据”否则一律用默认 seq_cst。另外特别提醒一点atomic_bool 只是让 worker 跳出循环它替代不了 join。如果停止后立刻销毁线程对象仍然要保证先 join否则会触发 std::terminate。4.3 一次性初始化compare_exchange 的活教材一次性初始化也就是“这么多线程同时执行但只让其中一个执行初始化逻辑”用 compare_exchange_strong 非常优雅class Once { public: bool call(std::functionvoid() fn) { bool expected false; if (initialized_.compare_exchange_strong(expected, true)) { fn(); return true; } return false; } private: std::atomic_bool initialized_{false}; };第一次发出调用时initialized_ 还是 falsecompare_exchange_strong 成功把它改成 true然后执行初始化。后续线程执行时期望值 false 和当前值 true 不相等compare_exchange 失败函数返回 false不会重复初始化。当然C11 标准库已经提供了std::call_once真实项目里没必要自己造轮子。但这个例子能帮助你理解 CAS 的用法它不仅能判断“别人做了没有”还能在判断的同时原子地修改状态中间的竞态窗口被完美消除。5. 常见问题与排查实录5.1 std::atomic_bool 和 std::atomic_flag 该选谁很多初学者会把这两个类型搞混因为它们听上去都是“原子布尔状态”。但它们其实是两个层次的东西。特性std::atomic_boolstd::atomic_flag是否保证 lock-free不保证保证支持 load/store支持不支持支持 exchange/CAS支持只有 test_and_set / clear语义完整的 bool 原子类型极简的“原子标志位”易用性高非常低atomic_flag 是标准里唯一保证在任何平台上都是 lock-free 的原子类型但代价是接口少得可怜只有 test_and_set设置并返回旧值和 clear清空。它更适合做极底层的自旋锁元语。而 atomic_bool 虽然理论上不保证 lock-free但在所有主流平台上基本都是无锁实现加上接口更丰富、语义更直观日常开发我会首选它。5.2 如何判断当前实现是否 lock-freeAtomic_bool 不保证 lock-free那怎么知道它在某个平台上是不是无锁答案是使用is_lock_free()接口C17 之后还有编译期常量is_always_lock_free。std::atomic_bool flag{false}; if (flag.is_lock_free()) { // 在当前实现上无锁 } if constexpr (std::atomic_bool::is_always_lock_free) { // 在所有支持的平台上都无锁 }我在 x86-64 和 ARM64 上实测std::atomic_bool 的 is_lock_free 都返回 true也就是说通常就是一条普通的读/写指令或者一条带锁前缀的 RMW 指令。但如果你做的是跨平台库还是建议用接口判断一下毕竟标准没有做出保证。5.3 CAS 伪失败与 ABA 问题前面提到 compare_exchange_weak 可能产生伪失败。这种失败在竞争激烈的多线程环境下更容易出现代码里一定要配合循环重试。举个例子bool expected false; while (!flag.compare_exchange_weak(expected, true)) { expected false; // 失败后 expected 可能已经被修改需要重置 }这里有个细节很多人会踩compare_exchange 失败时会把 expected 更新为当前值所以循环里要记得重新把 expected 设回初始值否则下一次判断条件就不对了。至于 ABA 问题说的是一个值从 A 变成 B 又变回 ACAS 会以为它“没有变过”。对 bool 这种只有两个值的类型来说理论上有 ABA 可能但在大多数实际场景里威胁不大。如果你拿原子变量做状态机状态不止两态或者“读旧值”和“写新值”之间依赖某种版本变化那就用std::atomicint并配合递增版本号比在 bool 上硬做安全得多。5.4 长等待别死等条件变量与 C20 wait自旋等待的优点是延迟低缺点是忙等待会持续占用 CPU。如果一个线程可能会被挂起几秒甚至更久再用while (!flag.load()) {}去等那就太浪费了。经典做法是用条件变量线程在条件不满足时睡眠条件满足时被唤醒。std::mutex mtx; std::condition_variable cv; bool ready false; void consumer() { std::unique_lockstd::mutex lock(mtx); cv.wait(lock, [] { return ready; }); } void producer() { { std::lock_guardstd::mutex lock(mtx); ready true; } cv.notify_one(); }C20 给原子类型增加了 wait / notify 系列接口让事情变得更简单了std::atomic_bool flag{false}; // 消费者线程 flag.wait(false); // 阻塞直到 flag 的值不再是 false // 生产者线程 flag.store(true); flag.notify_all();它的内部实现通常会先短暂自旋再进入真正的等待队列是自旋锁和条件变量之间的一个折中方案。如果你的项目已经用了 C20小信号量场景可以直接用这套不需要再自己封装一个“等待唤醒”的循环。6. 最后分享两个我真实踩过的坑第一个坑发生在很多年前我用volatile bool当停止标志当时我天真地以为 volatile 能保证“每次读取都从内存拿最新值”。实际上 volatile 在 C 里只告诉编译器不要对这个变量做某些优化它既不提供原子性也不提供内存序约束。在多核平台上修改可能仍然不会被其他线程及时看到代码照样会出现数据竞争。如果你还在用 volatile 解决并发同步请尽快换成 atomic 系列这是我能给的最直接的忠告。第二个坑是我当时给线程池设置了停止标志却没有及时 join。结果主函数已经准备结束worker 线程还在局部变量销毁之后访问已经失效的数据。atomic_bool 保证了标志本身读写安全但它不能替你规划对象的生命周期。并发控制不是“造一个原子变量”就完事你得想清楚每个线程什么时候退出、退出前要保证什么数据仍然存活。如果让我总结一条可复用的经验那就是std::atomic_bool 是把并发状态同步变成标准可预测行为的起点而不是终点。它在传递停止信号、构建简单锁、实现一次性初始化这些场景里非常可靠但真正的线程生命周期管理、任务队列的数据安全还需要集合 mutex、条件变量、join 这些基础组件一起来做。多线程程序没有银弹atomic_bool 只是工具箱里一个顺手且高效的工具罢了。
