C++内存模型基础多线程内存访问规则-C++-PHP中文网

C++内存模型基础多线程内存访问规则

P粉602998670

发布： 2025-08-20 08:51:01

原创

524人浏览过

C++内存模型通过happens-before和synchronizes-with关系，利用std::atomic和内存屏障确保多线程下操作的可见性与顺序性，防止数据竞争；其中memory_order提供不同强度的排序控制，release-acquire配对可实现高效同步，而seq_cst提供最强一致性；内存屏障则用于非原子变量的跨线程可见性控制，避免指令重排，确保程序行为可预测。

c++内存模型基础多线程内存访问规则

C++的内存模型，说白了，就是一套规则，它定义了在多线程环境下，不同线程对内存的读写操作会以怎样的顺序被观察到，以及这些操作何时能对其他线程可见。它解决了编译器和硬件为了性能优化而进行的指令重排问题，确保你在多线程程序中能写出可预测、正确运行的代码，避免那些难以捉摸的并发bug。

解决方案

要正确处理C++多线程中的内存访问，核心在于理解并利用C++内存模型提供的同步原语。这套模型引入了“happens-before”关系和“synchronizes-with”关系，通过原子操作（

std::atomic

登录后复制

）和内存屏障（

std::atomic_thread_fence

登录后复制

）来强制执行特定的内存排序，从而保证数据在线程间的可见性和一致性。简单来说，就是告诉编译器和CPU：“嘿，这里有些操作不能乱序，而且它们的结果必须让其他线程及时看到。”我们不再是盲目地依赖操作系统的调度，而是有了更精细的控制手段。

std::atomic

登录后复制

是如何解决数据竞争的？

我个人觉得，

std::atomic

登录后复制

真是C++11并发编程里的一大福音，它直接把原子性这个概念提升到了语言层面。数据竞争（data race）是个老大难问题：当多个线程同时访问同一个内存位置，并且至少有一个是写操作，同时又没有任何同步机制时，就发生数据竞争了。这玩意儿会导致未定义行为，程序可能崩溃，也可能输出诡异的结果，而且这类bug往往很难复现和调试。

std::atomic

登录后复制

的作用就是保证对其操作的原子性，也就是这些操作要么全部完成，要么全部不完成，不会被其他线程的操作打断。更重要的是，它还能提供内存排序（memory ordering）的保证，这才是解决数据可见性问题的关键。

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

memory_order_relaxed
登录后复制
: 这是最宽松的内存序，它只保证操作本身的原子性，不提供任何跨线程的内存排序保证。比如说，你用它来做个简单的计数器，只关心最终值，不关心中间步骤的可见性，那它就很高效。但如果你想用这个计数器来同步其他非原子变量的访问，那可就得小心了，因为它不提供任何可见性保证。
memory_order_release
登录后复制
: 这是一个“释放”操作。它确保当前线程在执行这个原子写操作之前的所有写操作，都会在执行这个释放操作之后对其他线程可见。你可以把它想象成一个屏障，所有屏障前的写操作都必须在屏障后可见。
memory_order_acquire
登录后复制
: 这是一个“获取”操作。它确保当前线程在执行这个原子读操作之后，能看到其他线程在执行匹配的释放操作之前的所有写操作。这就像一个“门”，你通过这个门后，就能看到门前发生的一切。
memory_order_acq_rel
登录后复制
: 顾名思义，它结合了获取和释放的语义，用于读-改-写（RMW）操作，比如
```
fetch_add
```
登录后复制
。它既能保证读到最新值（获取），又能保证写入的值对其他线程可见（释放）。
memory_order_seq_cst
登录后复制
: 这是最强的内存序，也是默认的。它不仅保证原子性，还保证所有
```
seq_cst
```
登录后复制
操作在所有线程中都以相同的总顺序执行。这提供了最直观的“顺序一致性”，但代价是性能可能最低，因为它会强制编译器和CPU进行更多的同步。

通常情况下，如果你不确定，用

memory_order_seq_cst

登录后复制

是最安全的，但为了性能，我们常常会尝试用

release-acquire

登录后复制

配对来替代，因为它能提供足够的同步保证，同时又允许更多的优化。

内存屏障（Memory Fences）在多线程编程中的作用是什么？

有时候，你可能不想把所有变量都变成

std::atomic

登录后复制

，或者你需要更细粒度地控制非原子变量的可见性。这时候，内存屏障（memory fences），也就是

std::atomic_thread_fence

登录后复制

，就派上用场了。它不像

std::atomic

登录后复制

操作那样绑定到特定的变量上，而是一个独立的指令，用来在程序执行流中插入一个同步点，强制编译器和CPU遵守特定的内存排序规则。

存了个图

视频图片解析/字幕/剪辑，视频高清保存/图片源图提取

查看详情

说实话，这东西用起来比

std::atomic

登录后复制

更抽象一点，也更容易出错，但它确实有它的用武之地。比如，你可能有一个复杂的初始化过程，涉及到多个非原子变量的写入，你希望这些写入全部完成后，才能被其他线程看到。你可以在所有写入完成后，放置一个

std::atomic_thread_fence(std::memory_order_release)

登录后复制

。然后，在另一个线程准备读取这些变量之前，放置一个

std::atomic_thread_fence(std::memory_order_acquire)

登录后复制

。这样就能保证可见性了，而不需要把每个变量都原子化。

它的作用就是防止指令重排跨越屏障。一个

release

登录后复制

屏障会阻止它之前的读写操作被重排到它之后；一个

acquire

登录后复制

屏障会阻止它之后的读写操作被重排到它之前。

seq_cst

登录后复制

屏障则提供了最强的全局顺序保证。这就像在代码里设置了一个检查点，确保某些操作的顺序和可见性。

什么是“happens-before”关系，它如何影响多线程程序的行为？

“happens-before”关系，是C++内存模型里最核心、也是最抽象的一个概念。它不是指时间上的先后顺序，而是一种偏序关系，定义了操作之间的可见性。如果操作A happens-before 操作B，那么操作A的所有可见效果（比如对内存的写入）都必须对操作B可见。简单来说，就是A的改变在B发生时，B一定能看到。

理解这个概念，是理解C++多线程程序行为的关键。如果没有明确的 happens-before 关系来连接两个线程对同一内存位置的访问，并且至少一个是写入，那恭喜你，你很可能遇到了数据竞争，其结果是未定义行为。

happens-before 关系的建立方式主要有几种：

单线程内部顺序（Sequenced-before）: 在同一个线程内部，代码的执行顺序自然形成 happens-before 关系。
跨线程同步（Synchronizes-with）: 这是多线程编程中最重要的部分。当一个操作“synchronizes-with”另一个操作时，就建立了 happens-before 关系。常见的例子包括：
- 原子操作的 release-acquire 配对: 一个线程的
```
release
```
  登录后复制
  操作（如
```
atomic_flag::test_and_set
```
  登录后复制
  或
```
std::atomic
```
  登录后复制
  的
```
memory_order_release
```
  登录后复制
  写）synchronizes-with 另一个线程对同一个原子变量的
```
acquire
```
  登录后复制
  操作（如
```
atomic_flag::clear
```
  登录后复制
  或
```
std::atomic
```
  登录后复制
  的
```
memory_order_acquire
```
  登录后复制
  读）。
- 互斥锁（
  std::mutex
  登录后复制
  ）: 一个线程释放锁 synchronizes-with 另一个线程获取同一把锁。
- 线程的启动和结束: 一个线程的创建（
```
std::thread
```
  登录后复制
  构造函数）synchronizes-with 新线程的开始执行。一个线程的结束（
```
std::thread::join
```
  登录后复制
  ）synchronizes-with 另一个线程的
```
join
```
  登录后复制
  返回。

如果两个操作之间没有 happens-before 关系，或者它们之间存在一个竞争条件，那么程序的行为就是未定义的。这意味着编译器可以做任何它想做的事情，你的程序可能崩溃，也可能输出错误的结果，甚至在不同的运行环境或编译选项下表现不同。这也就是为什么并发编程如此困难，因为这些问题往往是隐蔽的，而且很难调试。所以，在设计多线程程序时，我们总是需要确保所有共享数据的访问都通过