C++原子操作与内存顺序memory_order使用

P粉602998670

发布时间：2025-09-18 11:35:01

326人浏览过

来源于php中文网

原创

原子操作保证单个变量的读写不可中断，内存顺序控制多线程下操作的可见性与顺序，二者结合可在无锁情况下实现高效、正确的并发编程。

c++原子操作与内存顺序memory_order使用

C++的原子操作和内存顺序，在我看来，是多线程编程里一把双刃剑，它能让你在无锁并发的世界里翩翩起舞，也能在你一个不慎时，把你摔得七荤八素。简单来说，原子操作保证了单个变量的读写或修改是不可中断的，就像一个事务，要么完成，要么不发生。而内存顺序（

memory_order

）则是用来告诉编译器和CPU，这些原子操作之间以及它们与其他非原子操作之间，应该以何种顺序被观察到，这直接决定了不同线程看到的数据一致性程度。理解并正确运用它们，是编写高性能、正确多线程代码的关键。

解决方案

要深入理解并运用C++的原子操作与内存顺序，我们首先得认识到它们是为了解决传统锁机制（如

std::mutex

）在某些场景下的性能瓶颈和粒度问题而生。C++11引入的

std::atomic

模板类及其相关的内存顺序枚举，提供了一套细粒度的并发控制手段。

核心在于

std::atomic<T>

类型，它确保了对

类型变量的任何操作（如读、写、修改）都是原子的。这意味着，即使在多线程环境下，一个线程对原子变量的操作也不会被其他线程“看到一半”。但仅仅原子性还不够，因为现代CPU和编译器为了性能，会进行指令重排和内存访问优化，这可能导致不同线程观察到操作的顺序与代码编写顺序不一致。这就是

memory_order

登场的原因。

memory_order

枚举定义了六种内存顺序：

立即学习“C++免费学习笔记（深入）”；

```
memory_order_relaxed
```
：最宽松的顺序，只保证操作本身的原子性，不提供任何跨线程的同步或排序保证。
```
memory_order_consume
```
：消费顺序。读操作依赖于另一个线程的写操作，且只对数据依赖的后续操作提供排序。这个很复杂，实际中常被编译器优化为
```
acquire
```
。
```
memory_order_acquire
```
：获取顺序。一个线程的
```
acquire
```
操作能看到另一个线程在
```
release
```
操作之前的所有写操作。
```
memory_order_release
```
：释放顺序。一个线程的
```
release
```
操作确保所有在此操作之前的写操作，对后续进行
```
acquire
```
操作的线程可见。
```
memory_order_acq_rel
```
：获取-释放顺序。用于读-改-写操作，同时具备
```
acquire
```
和
```
release
```
的语义。
```
memory_order_seq_cst
```
：顺序一致性。最严格的顺序，保证所有
```
seq_cst
```
操作在一个全局总序中被观察到。这是
```
std::atomic
```
操作的默认内存顺序。

实际应用中，我们通常会结合

load()

、

store()

、

exchange()

、

compare_exchange_weak()

、

compare_exchange_strong()

、

fetch_add()

等原子操作成员函数来指定内存顺序。

#include <atomic>
#include <thread>
#include <vector>
#include <iostream>

std::atomic<int> counter(0); // 默认memory_order_seq_cst

void increment_counter() {
    for (int i = 0; i < 10000; ++i) {
        counter.fetch_add(1, std::memory_order_relaxed); // 简单计数，不需要严格顺序
    }
}

std::atomic<bool> ready(false);
std::atomic<int> data(0);

void producer() {
    data.store(42, std::memory_order_release); // 写入数据，并释放内存顺序
    ready.store(true, std::memory_order_release); // 设置就绪标志，并释放内存顺序
}

void consumer() {
    while (!ready.load(std::memory_order_acquire)) { // 等待就绪，并获取内存顺序
        std::this_thread::yield(); // 避免忙等
    }
    // 此时，data.load()将保证看到42，因为ready的acquire与producer的release同步
    std::cout << "Data is: " << data.load(std::memory_order_relaxed) << std::endl;
}

int main() {
    std::vector<std::thread> threads;
    for (int i = 0; i < 10; ++i) {
        threads.emplace_back(increment_counter);
    }
    for (auto& t : threads) {
        t.join();
    }
    std::cout << "Final counter: " << counter.load() << std::endl; // 默认seq_cst加载

    std::thread p(producer);
    std::thread c(consumer);
    p.join();
    c.join();

    return 0;
}

为什么我们需要原子操作，普通锁不够吗？

这确实是个好问题，初学者往往会疑惑，既然有

std::mutex

这样的锁可以保护共享数据，为什么还要引入原子操作和这么复杂的内存顺序呢？在我看来，这就像是修房子，锁是把整个房间锁起来，而原子操作则是给房间里某件特定物品加了个保险箱。

普通锁（互斥量）的粒度通常比较粗。它保护的是一段代码块，也就是所谓的“临界区”。当一个线程进入临界区时，它会获得锁，其他试图进入的线程就必须等待。这种机制简单有效，能确保临界区内的所有操作都是串行执行的，从而避免数据竞争。然而，它的缺点也很明显：

性能开销： 锁的获取和释放本身是有开销的，涉及到操作系统调用或复杂的同步指令。在高并发、临界区很短的场景下，锁的开销可能远大于实际业务逻辑的开销，导致性能下降。
粒度问题： 锁一次性保护了整个临界区，即使临界区内只有一小部分操作涉及共享数据，其他不相关的操作也可能被无谓地串行化，降低了并行度。
死锁风险： 使用锁时，需要非常小心地管理锁的顺序，否则很容易引入死锁问题，导致程序挂起。

原子操作则提供了一种“无锁（lock-free）”或“非阻塞（non-blocking）”的并发控制手段。它主要针对单个变量的读、写、修改操作。CPU提供了特殊的指令（例如，x86架构上的

LOCK

前缀指令，或者特定的CAS – Compare-And-Swap指令），这些指令能够保证在执行过程中不会被其他CPU核心中断。

对比来看：

性能： 对于单个变量的简单操作，原子操作通常比加锁的开销小得多。它们避免了操作系统上下文切换、线程阻塞和唤醒的开销。在某些高并发场景下，无锁算法能展现出更好的扩展性。
粒度： 原子操作的粒度是最小的，它只保护了单个变量的访问。这使得我们可以更精细地控制并发，提高程序的并行度。
避免死锁： 因为没有“锁”的概念，自然也就没有死锁的风险。

当然，原子操作并非万能药。它们只适用于单个变量的操作。如果需要保护多个变量或复杂的复合操作，那么锁仍然是更直接、更安全的方案。原子操作的复杂性在于，一旦脱离了默认的

seq_cst

，你就必须深入理解内存模型和不同

memory_order

的语义，否则很容易引入难以调试的并发错误。所以，选择原子操作还是锁，本质上是一个权衡：在需要极致性能和精细控制的场景下，原子操作是强大的工具；而在追求开发效率和代码简洁性时，锁往往是更稳妥的选择。

PathFinder

AI驱动的销售漏斗分析工具

下载

深入理解C++内存模型：不同memory_order的实际影响与选择

C++内存模型这东西，坦白说，初次接触时会让人觉得有点玄乎，它描述的是多线程程序中，内存操作的可见性和顺序性规则。不同的

memory_order

就是我们用来与这个模型“对话”的语言，告诉它我们对这些规则的具体要求。理解它们实际影响，是避免并发bug的关键。

```
std::memory_order_relaxed
```
：性能至上，风险并存
- 实际影响： 这是最弱的内存顺序。它只保证原子操作本身是不可分割的，但不保证任何操作之间的顺序性。这意味着，一个线程对
```
relaxed
```
  原子变量的写入，可能在另一个线程观察到该写入之前，先观察到这个线程后续的非原子写入。编译器和CPU可以随意重排
```
relaxed
```
  操作，只要不改变单个线程内的行为。
- 选择场景： 适用于那些只关心最终结果，不关心中间状态或操作顺序的简单计数器。比如，一个全局的统计数字，每个线程只管加一，最终总和正确即可。
- 风险： 如果你的代码中存在任何对数据可见性或操作顺序的隐式依赖，使用
```
relaxed
```
  几乎必然导致难以复现的bug。
```
std::atomic<int> x(0);
std::atomic<int> y(0);

void thread1() {
    x.store(1, std::memory_order_relaxed);
    y.store(1, std::memory_order_relaxed); // y可能在x之前被其他线程看到
}

void thread2() {
    while (y.load(std::memory_order_relaxed) == 0); // 等待y被写入
    // 此时x.load()可能仍为0，因为relaxed不提供排序保证
    if (x.load(std::memory_order_relaxed) == 0) {
        std::cout << "Surprise! x is still 0 even after y is 1." << std::endl;
    }
}
```
```
std::memory_order_release
```
和
std::memory_order_acquire
：构建同步屏障
- 实际影响： 这是构建无锁数据结构和实现线程间通信的基石。
```
release
```
  操作确保了所有在它之前的内存写入（包括非原子写入）都会在
```
release
```
  操作完成前完成并对其他线程可见。
```
acquire
```
  操作则保证了所有在它之后的内存读取（包括非原子读取）都会在
```
acquire
```
  操作完成之后执行，并且能够看到对应
```
release
```
  操作之前的所有写入。它们共同建立了一个“ happens-before ”关系。
- 选择场景： 经典的生产者-消费者模型。生产者写入数据后，执行
```
release
```
  操作，表示数据已准备好；消费者执行
```
acquire
```
  操作来检查数据是否准备好。一旦
```
acquire
```
  成功，消费者就能保证看到生产者在
```
release
```
  之前写入的所有数据。
- 核心理念：
```
release
```
  操作是“释放”了所有之前写入的可见性，
```
acquire
```
  操作是“获取”了这些写入的可见性。
```
std::atomic<int> data_item(0);
std::atomic<bool> data_ready(false);

void producer_thread() {
    data_item.store(100, std::memory_order_relaxed); // 写入数据
    data_ready.store(true, std::memory_order_release); // 释放，确保data_item可见
}

void consumer_thread() {
    while (!data_ready.load(std::memory_order_acquire)) { // 获取，等待data_ready为true
        std::this_thread::yield();
    }
    // 此时，data_item.load()保证能看到100
    std::cout << "Consumed: " << data_item.load(std::memory_order_relaxed) << std::endl;
}
```
```
std::memory_order_acq_rel
```
：读-改-写操作的同步
- 实际影响： 顾名思义，它结合了
```
acquire
```
  和
```
release
```
  的语义。用于那些需要先读取一个值，然后根据读取的值进行修改，最后将新值写回的原子操作（如
```
fetch_add
```
  、
```
compare_exchange
```
  ）。它确保了读取操作能看到之前所有线程的写入，并且它本身的写入操作也能对后续的
```
acquire
```
  操作可见。
- 选择场景： 需要原子地更新一个共享变量，并且这个更新操作本身需要同步。例如，一个原子计数器，在更新时需要确保看到最新的值，并且更新后的值也要及时对其他线程可见。
- 例子：
```
counter.fetch_add(1, std::memory_order_acq_rel);
```
  这种操作在内部会先读取
```
counter
```
  的当前值（
```
acquire
```
  语义），然后加1，再将新值写回（
```
release
```
  语义）。
```
std::memory_order_seq_cst
```
：最强保证，最易理解，但最慢
- 实际影响： 提供最强的内存排序保证，所有使用
```
seq_cst
```
  的原子操作都会在一个全局的、唯一的总序中被观察到。这意味着，所有线程对
```
seq_cst
```
  操作的观察顺序都是一致的，并且所有
```
seq_cst
```
  操作都不能被重排。
- 选择场景： 当你对内存顺序有疑问，或者需要最简单、最直观的并发行为时，
```
seq_cst
```
  是你的首选。它能有效避免各种复杂的内存重排问题，让代码行为更可预测。
- 代价： 这种强保证通常伴随着最高的性能开销，因为它可能需要更多的CPU指令或内存屏障来强制排序。
- 默认值： C++标准中，所有
```
std::atomic
```
  操作的默认内存顺序都是
```
seq_cst
```
  。如果你不指定，就是它在起作用。
```
std::memory_order_consume
```
：一个复杂且不常用的选项
- 实际影响： 它比
```
acquire
```
  弱，只对那些“数据依赖”于
```
consume
```
  加载值的后续操作提供排序保证。例如，如果你加载了一个指针，然后通过这个指针访问数据，
```
consume
```
  能保证指针指向的数据是可见的。
- 选择场景： 理论上可以提供比
```
acquire
```
  更好的性能，但其语义非常复杂，难以正确使用，且编译器实现上往往直接将其提升为
```
acquire
```
  ，导致其性能优势不明显。
- 建议： 如果不是对C++内存模型有极其深入的理解，并且有明确的性能瓶颈需要优化，通常建议避免使用
```
consume
```
  ，而直接使用
```
acquire
```
  。

选择正确的

memory_order

，本质上是在正确性和性能之间做权衡。从最强的

seq_cst

开始，如果发现性能瓶颈，再逐步尝试放宽到

acq_rel

、

acquire/release

，甚至是

relaxed

，但每一步都需要经过严谨的测试和分析，以确保没有引入新的并发问题。这需要对并发编程有深刻的理解和实践经验。

避免常见陷阱：原子操作与内存顺序的错误使用分析

在我看来，原子操作和内存顺序就像是精密的手术刀，用好了能切中要害，效率奇高；用不好，就可能伤及无辜，甚至导致整个系统崩溃。这里列举一些我在实践中遇到或观察到的常见陷阱：

忘记原子性：将
```
std::atomic
```
当作普通变量使用 这是一个非常常见的初学者错误。
```
std::atomic<int> value;
```
声明了一个原子整数，但如果你直接写
```
int temp = value;
```
或者
```
value = temp + 1;
```
，而不是使用
```
value.load()
```
、
```
value.store()
```
或
```
value.fetch_add()
```
等成员函数，那么这些操作的原子性就可能无法保证。虽然现代编译器在某些简单场景下可能会“魔法般地”让这些操作看起来是原子的（尤其是对于像
```
int
```
这样的小类型），但这并不是标准保证的行为，并且会让你失去控制内存顺序的能力。
- 正确做法： 始终通过
```
std::atomic
```
  提供的成员函数来访问和修改原子变量。
```
memory_order_relaxed
```
的滥用
```
relaxed
```
是最宽松的内存顺序，性能最好，但也最危险。很多人看到“性能最好”就想用它，但却忽略了它不提供任何跨线程的排序保证。
- 陷阱： 假设一个线程写入了两个
```
relaxed
```
  原子变量
```
A
```
  和
```
B
```
  ，另一个线程读取
```
A
```
  和
```
B
```
  。即使写入线程先写入
```
A
```
  再写入
```
B
```
  ，读取线程也可能先看到
```
B
```
  的更新，然后才看到
```
A
```
  的更新，甚至永远看不到
```
A
```
  的更新，如果
```
A
```
  和
```
B
```
  之间存在隐式的数据依赖，这就会导致程序逻辑错误。
- 示例： 生产者写入数据
```
data
```
  ，然后设置
```
flag
```
  为true。消费者等待
```
flag
```
  为true后读取
```
data
```
  。如果
```
data
```
  和
```
flag
```
  都用
```
relaxed
```
  ，消费者可能在
```
flag
```
  为true后，仍然读到旧的
```
data
```
  值。
- 避免： 除非你明确知道你的操作不需要任何排序，并且已经仔细分析过所有潜在的并发路径，否则不要轻易使用
```
relaxed
```
  。
误解
```
acquire/release
```
的同步范围
```
acquire/release
```
语义是C++内存模型中非常强大的工具，但它的同步范围常常被误解。
- 陷阱：
```
release
```
  操作只保证其之前的写入对匹配的
```
acquire
```
  操作可见。它不保证
```
release
```
  操作之后的写入会提前对其他线程可见。同样，
```
acquire
```
  操作只保证其之后的读取能看到匹配
```
release
```
  操作之前的写入。它不保证
```
acquire
```
  操作之前的读取能看到