C++并发特性原子操作内存模型-C++-PHP中文网

答案：C++原子操作与内存模型通过std::atomic和内存顺序提供多线程同步保障，避免数据竞争与可见性问题，其中不同memory_order在性能与同步强度间权衡，而无锁结构依赖CAS等原子操作，但需应对ABA和内存回收等挑战。

c++并发特性原子操作内存模型

C++并发特性中的原子操作和内存模型，核心在于它们为多线程环境下的数据同步与一致性提供了底层保障。简单来说，它们定义了在多个线程同时读写共享数据时，这些操作应该如何被编译器和处理器处理，以及它们的效果如何对其他线程可见，以此避免数据竞争和各种难以追踪的并发错误。

解决方案

理解C++的原子操作和内存模型，就好比掌握了在多变且充满不确定性的并发世界中，如何给你的数据穿上“防弹衣”，并确保信息传递的“可靠信道”。

首先，原子操作，顾名思义，是不可分割的操作。这意味着，当一个线程执行一个原子操作时，其他线程无法观察到这个操作的中间状态，它要么完全完成，要么根本不发生。在多核处理器上，这通常通过特殊的CPU指令（如锁前缀指令）或总线锁定来实现。C++标准库通过

std::atomic<T>

登录后复制

模板类将这些底层复杂性抽象出来，提供了一系列原子操作，比如原子地读取（

load

登录后复制

）、写入（

store

登录后复制

）、交换（

exchange

登录后复制

）、比较并交换（

compare_exchange_weak

登录后复制

strong

登录后复制

）等。它们是构建无锁（lock-free）数据结构和算法的基石，因为它们允许我们以最小的粒度进行同步，避免了传统互斥锁带来的开销和潜在死锁问题。

然而，仅仅保证操作的原子性是不够的。即使一个操作是原子的，它在内存中的可见性以及与其他操作的相对顺序，仍然可能被编译器优化和处理器乱序执行所打乱。这就是内存模型登场的地方。C++内存模型（C++ Memory Model）定义了程序中所有线程对内存的访问行为，以及这些访问如何相互作用。它通过内存顺序（memory order）的概念，允许程序员精确控制原子操作的可见性和排序保证。这解决了几个核心问题：

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

编译器重排序（Compiler Reordering）：编译器为了优化性能，可能会改变指令的执行顺序。
处理器重排序（Processor Reordering）：CPU为了提高吞吐量，也可能乱序执行指令。
缓存一致性（Cache Coherence）：不同CPU核心有自己的缓存，一个核心对共享数据的修改，可能不会立即对其他核心可见。

内存模型提供了一套规则，让我们可以指定原子操作的“强度”，从而限制这些重排序和缓存同步的行为。理解并正确运用这些内存顺序，是编写正确、高效并发代码的关键。

为什么在C++并发编程中，普通变量的读写会引发问题？

这几乎是每一个初涉并发编程的人都会遇到的“坑”。我记得自己刚开始接触多线程时，总觉得只要变量是全局的，或者通过指针传递，大家都能访问到，那不就得了？结果往往是程序崩溃，或者出现一些难以复现的“幽灵”bug。问题根源在于数据竞争（Data Race）和由此导致的未定义行为（Undefined Behavior, UB）。

当两个或更多线程同时访问同一个共享内存位置，并且其中至少一个访问是写入操作，同时没有任何同步机制来协调这些访问时，数据竞争就发生了。最典型的例子就是简单的

int counter = 0;

登录后复制

，然后多个线程去执行

counter++;

登录后复制

。你可能以为

counter++

登录后复制

就一行代码，但实际上它通常包含三步：读取

counter

登录后复制

的值、将值加一、将新值写回

counter

登录后复制

。如果两个线程同时执行这个序列，它们可能都读到旧值，然后都基于旧值进行加一，最后都写回自己的结果，导致

counter

登录后复制

最终的值比预期的小。

更糟糕的是，C++标准明确规定，发生数据竞争会导致未定义行为。这意味着编译器可以做任何事情：程序可能崩溃，可能产生错误的结果，也可能在你的机器上运行正常，但在客户的机器上就出问题。这种不确定性是并发编程中最可怕的敌人，因为它让调试变得异常困难，就像在黑暗中追捕一个隐形的敌人。

此外，编译器和处理器为了性能优化，会进行指令重排序。一个线程写入的数据，可能因为缓存在本地，或者写入操作被延迟，而不会立即对其他线程可见。这就引出了可见性问题。线程A修改了共享变量，线程B却可能还在读取这个变量的旧值，因为它从自己的缓存中获取，而不是从主内存中。这些都是普通变量读写在并发环境下“不安全”的原因。

C++内存模型中的不同内存顺序（Memory Order）有哪些，它们各自的适用场景是什么？

C++内存模型通过

std::memory_order

登录后复制

枚举类型，为原子操作提供了多种内存顺序选项，它们在性能和同步强度之间进行了权衡。理解这些选项及其适用场景，是编写高效并发代码的关键。

```
std::memory_order_relaxed
```
登录后复制
(松散顺序)

盘古大模型
华为云推出的一系列高性能人工智能大模型

35

查看详情
- 特性： 这是最弱的内存顺序。它只保证操作本身的原子性，不提供任何跨线程的排序保证，也不保证与程序中其他非原子操作的顺序。
- 适用场景： 当你只需要一个原子计数器，且不关心这个计数器值的更新何时对其他线程可见，或者不关心它与其他操作的相对顺序时，可以使用它。比如，一个全局的事件统计器，只关心最终总数，不关心中间的可见性。
- 思考： 性能最高，但最危险，因为它几乎不提供任何同步保证。
```
std::memory_order_acquire
```
登录后复制
(获取顺序) /
std::memory_order_release
登录后复制
(释放顺序)
- 特性： 这是一对协同工作的内存顺序。
  - ```
  release
```
  登录后复制
  操作保证，所有在它之前发生的内存写入操作，在它完成后都会对其他线程可见。
- ```
acquire
```
    登录后复制
    操作保证，所有在它之后发生的内存读取操作，都会看到在与之同步的
```
release
```
    登录后复制
    操作之前发生的内存写入。
  - 简单来说，
```
release
```
    登录后复制
    “发布”了它之前的所有修改，
```
acquire
```
    登录后复制
    “看到了”这些修改。
- 适用场景： 典型的“生产者-消费者”模型，或者实现简单的自旋锁、标志位。例如，一个线程写入数据后，设置一个
```
std::atomic<bool>
```
  登录后复制
  标志为
```
true
```
  登录后复制
  （
```
release
```
  登录后复制
  ），另一个线程循环读取这个标志直到它变为
```
true
```
  登录后复制
  （
```
acquire
```
  登录后复制
  ），然后处理数据。这确保了数据在标志被设置之前已经完全写入并可见。
- 思考： 提供了足够的同步保证，同时比
```
seq_cst
```
  登录后复制
  更灵活，性能也更好。这是实际并发编程中非常常用的一种模式。
```
std::memory_order_acq_rel
```
登录后复制
(获取-释放顺序)
- 特性： 用于读-改-写（RMW）原子操作，如
```
fetch_add
```
  登录后复制
  、
```
compare_exchange
```
  登录后复制
  等。它结合了
```
acquire
```
  登录后复制
  和
```
release
```
  登录后复制
  的特性：该操作既像一个
```
acquire
```
  登录后复制
  操作一样，确保其后的读操作能看到之前的写入；又像一个
```
release
```
  登录后复制
  操作一样，确保其前的写入对其他线程可见。
- 适用场景： 多个线程同时更新一个共享变量，并且需要保证更新的顺序和可见性。比如，原子地递增一个计数器，并确保这个递增操作本身以及它之前的所有写入都对其他线程可见。
```
std::memory_order_seq_cst
```
登录后复制
(顺序一致性)
- 特性： 这是最严格的内存顺序，也是
```
std::atomic
```
  登录后复制
  操作的默认顺序。它不仅保证原子性，还保证所有
```
seq_cst
```
  登录后复制
  操作在所有线程中都以相同的总顺序（total order）执行。这意味着，所有线程对
```
seq_cst
```
  登录后复制
  操作的观察结果都是一致的，就像有一个全局的时钟在同步它们一样。
- 适用场景： 当你需要最强的同步保证，或者对并发模型理解不深时，这是一个安全的默认选择。它能有效避免各种复杂的重排序问题，但通常伴随着最高的性能开销，因为它可能需要更昂贵的同步指令。
- 思考： 保证了直观的“顺序”，但也牺牲了部分性能。如果性能不是瓶颈，或者你对并发的理解尚浅，这是一个很好的起点。

实际工作中，我发现很多人在不确定时会直接使用

seq_cst

登录后复制

，这通常是安全的，但如果性能是关键考量，深入理解

acquire

登录后复制

release

登录后复制

对会非常有价值。

如何利用C++原子操作构建高效且无锁的并发数据结构？

构建无锁（lock-free）数据结构是并发编程领域的一项高级挑战，它旨在通过原子操作而非传统互斥锁来管理共享数据，从而避免死锁、优先级反转等问题，并可能在某些场景下提供更高的吞吐量。然而，这并非易事，充满了陷阱。

核心武器是比较并交换（Compare-And-Swap, CAS）操作，在C++中由

std::atomic::compare_exchange_weak

登录后复制

和

std::atomic::compare_exchange_strong

登录后复制

提供。CAS操作的基本思想是：读取一个内存位置的当前值，与预期值进行比较，如果相等，则将该位置更新为新值，这是一个原子操作。如果比较失败，说明在读取到旧值和尝试写入新值之间，有其他线程修改了该内存位置，此时当前线程可以重试。

以一个简单的无锁计数器为例：

std::atomic<int> counter{0};

void increment() {
    int expected = counter.load(std::memory_order_relaxed); // 松散读取当前值
    int desired;
    do {
        desired = expected + 1;
        // 尝试将counter从expected更新为desired
        // 如果失败（expected与当前counter值不符），则更新expected并重试
    } while (!counter.compare_exchange_weak(expected, desired,
                                         std::memory_order_relaxed, // 成功时的内存顺序
                                         std::memory_order_relaxed)); // 失败时的内存顺序
}

登录后复制

这段代码中，

compare_exchange_weak

登录后复制

尝试原子地将

counter

登录后复制

从

expected

登录后复制

（我们认为的旧值）更新为

desired

登录后复制

（新值）。如果

counter

登录后复制

的实际值与

expected

登录后复制

不符，说明在读取

expected

登录后复制

到执行

compare_exchange_weak

登录后复制

之间，

counter

登录后复制

已经被其他线程修改了。此时

compare_exchange_weak

登录后复制

会返回

false

登录后复制

，并将

counter

登录后复制

的当前值写入

expected

登录后复制

，循环继续，我们就可以用新的

expected

登录后复制

值再次尝试。

除了CAS，构建复杂无锁数据结构还需要考虑：

ABA问题： 假设线程A读取了值A，然后被调度出去。线程B执行了一些操作，将值从A改为B，再改回A。当线程A再次被调度时，它会发现值仍然是A，认为没有发生变化，然后继续执行，但这可能是错误的，因为中间状态发生了改变。解决ABA问题通常需要“标记指针”（tagged pointers），即在指针中加入一个版本号或计数器，每次更新指针时也更新版本号，这样即使值回到了A，版本号也不同了。
内存回收（Memory Reclamation）： 这是无锁编程中最棘手的问题之一。当一个节点从无锁数据结构中被移除时，我们不能立即释放其内存，因为其他线程可能仍然持有指向该节点的指针。如果立即释放，并被其他线程重新分配使用，那些持有旧指针的线程就可能访问到无效或不相关的数据，导致崩溃。常见的解决方案包括：
- 引用计数（Reference Counting）：但原子引用计数本身可能成为性能瓶颈。
- Hazard Pointers（危险指针）：每个线程维护一个列表，列出它当前正在访问的节点。只有当一个节点不在任何线程的危险指针列表中时，才能安全回收。
- Read-Copy-Update (RCU)：一种更复杂的机制，通常用于读多写少的场景，它允许读者不加锁地访问数据，而写者则创建数据的副本进行修改，修改完成后原子地替换旧数据。