C++内存模型通过happens-before和synchronizes-with关系，利用std::atomic和内存屏障确保多线程下操作的可见性与顺序性，防止数据竞争；其中memory_order提供不同强度的排序控制，release-acquire配对可实现高效同步，而seq_cst提供最强一致性；内存屏障则用于非原子变量的跨线程可见性控制，避免指令重排，确保程序行为可预测。
C++的内存模型，说白了，就是一套规则，它定义了在多线程环境下，不同线程对内存的读写操作会以怎样的顺序被观察到，以及这些操作何时能对其他线程可见。它解决了编译器和硬件为了性能优化而进行的指令重排问题，确保你在多线程程序中能写出可预测、正确运行的代码，避免那些难以捉摸的并发bug。
解决方案
要正确处理C++多线程中的内存访问，核心在于理解并利用C++内存模型提供的同步原语。这套模型引入了“happens-before”关系和“synchronizes-with”关系，通过原子操作（
std::atomic
）和内存屏障（
std::atomic_thread_fence
）来强制执行特定的内存排序，从而保证数据在线程间的可见性和一致性。简单来说，就是告诉编译器和CPU：“嘿，这里有些操作不能乱序，而且它们的结果必须让其他线程及时看到。”我们不再是盲目地依赖操作系统的调度，而是有了更精细的控制手段。
std::atomic
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 关系，或者它们之间存在一个竞争条件，那么程序的行为就是未定义的。这意味着编译器可以做任何它想做的事情，你的程序可能崩溃，也可能输出错误的结果，甚至在不同的运行环境或编译选项下表现不同。这也就是为什么并发编程如此困难，因为这些问题往往是隐蔽的，而且很难调试。所以，在设计多线程程序时，我们总是需要确保所有共享数据的访问都通过
std::atomic
或互斥锁等同步机制建立了明确的 happens-before 关系。
以上就是C++内存模型基础 多线程内存访问规则的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/1472076.html
微信扫一扫 
支付宝扫一扫 
