原子操作保证单个变量的读写不可中断，内存顺序控制多线程下操作的可见性与顺序，二者结合可在无锁情况下实现高效、正确的并发编程。
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 #include #include #include std::atomic counter(0); // 默认memory_order_seq_cstvoid increment_counter() { for (int i = 0; i < 10000; ++i) { counter.fetch_add(1, std::memory_order_relaxed); // 简单计数，不需要严格顺序 }}std::atomic ready(false);std::atomic 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 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
的语义，否则很容易引入难以调试的并发错误。所以，选择原子操作还是锁，本质上是一个权衡：在需要极致性能和精细控制的场景下，原子操作是强大的工具；而在追求开发效率和代码简洁性时，锁往往是更稳妥的选择。
深入理解C++内存模型：不同memory_order的实际影响与选择
C++内存模型这东西，坦白说，初次接触时会让人觉得有点玄乎，它描述的是多线程程序中，内存操作的可见性和顺序性规则。不同的
memory_order
就是我们用来与这个模型“对话”的语言，告诉它我们对这些规则的具体要求。理解它们实际影响，是避免并发bug的关键。
std::memory_order_relaxed
：性能至上，风险并存
实际影响： 这是最弱的内存顺序。它只保证原子操作本身是不可分割的，但不保证任何操作之间的顺序性。这意味着，一个线程对
relaxed
原子变量的写入，可能在另一个线程观察到该写入之前，先观察到这个线程后续的非原子写入。编译器和CPU可以随意重排
relaxed
操作，只要不改变单个线程内的行为。选择场景： 适用于那些只关心最终结果，不关心中间状态或操作顺序的简单计数器。比如，一个全局的统计数字，每个线程只管加一，最终总和正确即可。风险： 如果你的代码中存在任何对数据可见性或操作顺序的隐式依赖，使用
relaxed
几乎必然导致难以复现的bug。
std::atomic x(0);std::atomic 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 data_item(0);std::atomic 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 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
操作之前的读取能看到
以上就是C++原子操作与内存顺序memory_order使用的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/1475874.html
微信扫一扫 
支付宝扫一扫 
