std::atomic通过原子操作确保线程安全，适用于单变量无锁编程，性能高但需谨慎使用内存序；而std::mutex提供更通用的互斥保护，适合复杂操作和数据结构，易于正确使用。选择取决于场景：简单原子操作用std::atomic，复合逻辑用std::mutex。
C++中，
std::atomic
提供了一种机制，确保对共享变量的操作是原子性的，即这些操作要么完全执行，要么根本不执行，并且在执行过程中不会被其他线程中断。这正是实现线程安全，避免数据竞争和未定义行为的核心手段。
解决方案
std::atomic
是C++标准库提供的一个模板类，它封装了一个类型，并为其提供了一系列原子操作。当我们说一个操作是“原子性的”，意味着它在多线程环境下是不可分割的。例如，一个简单的
int i = 0; i++;
看起来是一个操作，但在底层，它可能被分解为“读取
i
的值”、“将值加一”、“将新值写入
i
”这三个步骤。如果在多线程环境中，另一个线程可能在“读取”和“写入”之间修改了
i
的值，导致数据不一致。
std::atomic
就是为了解决这类问题而生。
使用
std::atomic
非常直观，你只需要将需要原子操作的类型封装起来：
#include #include #include #include std::atomic counter(0); // 初始化一个原子整数void increment_counter() { for (int i = 0; i < 100000; ++i) { counter++; // 原子递增操作 }}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 value: " << counter.load() << std::endl; // 原子读取 // 预期输出：1000000 return 0;}
在这个例子中，
counter++
实际上是一个原子性的“读取-修改-写入”操作（fetch_add）。
counter.load()
用于原子地读取当前值，
counter.store(value)
用于原子地写入一个值。此外，
std::atomic
还提供了
compare_exchange_weak
和
compare_exchange_strong
等更复杂的原子操作，它们是实现无锁算法（lock-free algorithms）的基石。这些操作允许你原子地比较一个值，并在满足条件时替换它，非常适合实现自旋锁或无锁数据结构。
立即学习“C++免费学习笔记（深入）”；
std::atomic 和互斥锁（std::mutex）有什么区别？什么时候该用哪个？
这是并发编程中一个非常常见且关键的问题。
std::atomic
和
std::mutex
都是用于实现线程安全的工具，但它们的设计理念、适用场景和性能特性有着显著的不同。
std::atomic
主要关注单个变量的原子操作。它通常是“无锁的”（lock-free），这意味着它通过底层CPU指令（如CAS，Compare-And-Swap）来保证操作的原子性，而不需要操作系统层面的互斥锁。无锁操作的优势在于，它避免了线程上下文切换的开销，理论上在竞争不激烈或只涉及单个简单数据类型时能提供更好的性能。它的粒度非常细，只保护单个变量的读写或修改。然而，
std::atomic
无法保证多个操作序列的原子性，也不能保护复杂的数据结构。
std::mutex
（互斥锁）则提供了一种更粗粒度的同步机制。它通过“锁定”一段代码区域或一组数据来防止多个线程同时访问。当一个线程获得互斥锁时，其他试图获取该锁的线程会被阻塞，直到锁被释放。
std::mutex
可以保护任意复杂的代码逻辑和数据结构，确保在锁定的范围内，数据的一致性和操作的原子性。但它的缺点是引入了锁的开销，包括锁的获取、释放以及可能的线程上下文切换，这在竞争激烈或锁持有时间较长时可能成为性能瓶颈。
何时选择哪个？
选择
std::atomic
：
当你只需要对单个简单数据类型（如
int
,
bool
, 指针）进行原子性的读、写、增、减或比较交换操作时。当你追求极致性能，且确信无锁方案能够满足需求时（但请注意，无锁编程比有锁编程更难正确实现）。例如，计数器、标志位、共享指针的引用计数等场景。你可以通过
std::atomic::is_lock_free()
来检查特定类型在当前平台上是否真的是无锁的。
选择
std::mutex
：
当你需要保护一段包含多个操作的代码逻辑，确保这些操作作为一个整体是原子性的。当你需要保护复杂的数据结构（如链表、哈希表、队列等），因为对这些结构的修改通常涉及多个步骤，
std::atomic
无法单独保证这些步骤的原子性。当你发现
std::atomic
无法满足你的复杂同步需求，或者无锁算法实现起来过于复杂且容易出错时。例如，修改银行账户余额（涉及读取、计算、写入多个步骤）、向共享队列添加或移除元素等场景。
有时候，两者甚至可以结合使用。例如，一个无锁队列可能在内部使用
std::atomic
来管理头尾指针，但对于队列元素的实际数据访问，可能仍然需要
std::mutex
或其他更复杂的无锁设计来保证数据一致性。我的经验是，如果不是对性能有极高的要求，且对并发模型有深入理解，通常会优先考虑
std::mutex
，因为它更容易理解和正确使用。
深入理解std::atomic的内存序（Memory Order）：性能与正确性的权衡
std::atomic
的强大之处不仅在于其原子操作本身，更在于其通过“内存序”（Memory Order）机制，允许开发者在性能和正确性之间进行精细的权衡。内存序定义了原子操作如何与程序中的其他内存操作（包括非原子操作）进行排序，从而影响不同线程观察到事件的顺序。理解这一点是掌握
std::atomic
的关键，也是并发编程中最容易出错但也最具优化潜力的部分。
默认情况下，
std::atomic
的所有操作都使用
std::memory_order_seq_cst
（顺序一致性）。这是最强也是最安全的内存序，它保证所有线程观察到的所有原子操作的顺序都是一致的，就像所有操作都发生在一个全局的单一时间线上一样。这种强保证通常通过内存屏障（memory barrier/fence）实现，可能会引入额外的性能开销，因为它限制了编译器和CPU的优化能力。
然而，在许多场景下，我们并不需要如此强的保证。C++11引入了多种内存序，允许我们根据实际需求放松这些限制：
std::memory_order_relaxed
：这是最弱的内存序。它只保证原子操作本身的原子性，不提供任何跨线程的排序保证。也就是说，一个线程对一个
relaxed
原子变量的写入，可能在另一个线程观察到该写入之前，先观察到该线程后续的其他非原子操作。它最快，但使用起来最危险，因为它完全依赖于程序员对并发模型的精确理解。通常只在计数器或一些不关心相对顺序的场景中使用。
std::memory_order_acquire
和
std::memory_order_release
：这两个内存序通常成对使用，用于建立“同步-发生”（synchronizes-with）关系，从而创建“先于发生”（happens-before）关系。
std::memory_order_release
： 确保当前线程中，所有在
release
操作之前的内存写入，都会在
release
操作完成后对其他线程可见。它就像一道门，保证在门关闭之前，所有东西都已就位。
std::memory_order_acquire
： 确保当前线程中，所有在
acquire
操作之后的内存读取，都能看到在
acquire
操作之前由其他线程
release
的所有写入。它就像一道门，保证在门打开之后，所有东西都已可见。当一个线程执行
release
操作，另一个线程执行
acquire
操作并成功看到
release
的结果时，
release
操作之前的所有内存写入都会对
acquire
操作之后的所有内存读取可见。这在生产者-消费者模型中非常有用。
std::atomic ready_flag(false);int data = 0;void producer() { data = 42; // 非原子写入 ready_flag.store(true, std::memory_order_release); // release 操作}void consumer() { while (!ready_flag.load(std::memory_order_acquire)); // acquire 操作 std::cout << "Data is: " << data << std::endl; // 保证能看到 42}
在这个例子中，
acquire-release
对保证了当
consumer
看到
ready_flag
为
true
时，它也一定能看到
data
被设置为
42
。
std::memory_order_acq_rel
：结合了
acquire
和
release
的语义，通常用于读-修改-写（RMW）操作，如
fetch_add
或
compare_exchange
。它既保证了操作之前的写入对其他线程可见，也保证了操作之后的读取能看到其他线程的最新写入。
权衡与选择：
内存序的选择是一个微妙的平衡。
seq_cst
最安全，但可能牺牲性能。
relaxed
最快，但最容易引入难以调试的并发错误。
acquire-release
对提供了一种中间地带，在保证特定同步需求的同时，允许更大的优化空间。
我个人在实践中，如果对并发模型没有百分之百的把握，或者性能瓶颈并不明显，我会倾向于使用默认的
std::memory_order_seq_cst
。它的“傻瓜式”安全性，能帮我避免很多头痛的问题。只有当性能分析明确指出原子操作的内存序是瓶颈时，我才会谨慎地考虑使用更弱的内存序。这通常需要对目标硬件的内存模型有一定了解，并进行大量的测试来验证正确性。毕竟，一个难以复现的并发bug，其代价往往远高于一点点性能提升。
使用std::atomic时常见的陷阱与最佳实践有哪些？
std::atomic
虽强大，但并非银弹。在使用它时，开发者常常会遇到一些陷阱，同时也积累了一些最佳实践。
常见的陷阱：
误以为所有操作都原子化：
std::atomic
只保证其自身成员函数的原子性。如果你有一个
std::atomic s;
，然后尝试
s.load().member = 5;
或者
s.member_function();
，这不是原子操作。
s.load()
会原子地获取
MyStruct
的一个副本，然后你修改的是这个副本，而不是共享的
s
本身。只有对
s
完整的赋值（
s = new_value;
）或读取（
MyStruct val = s.load();
）才是原子性的。对于复杂类型，你可能需要使用
std::atomic<std::shared_ptr>
或自己设计无锁结构。忘记内存序的重要性： 默认的
seq_cst
虽安全但可能效率不高，而为了性能盲目使用
relaxed
几乎肯定会引入难以追踪的并发bug。如前所述，不理解内存序而随意使用，是导致并发错误的主要原因之一。ABA 问题： 当使用
compare_exchange_weak
或
compare_exchange_strong
实现无锁算法时，可能会遇到 ABA 问题。即一个值从 A 变为 B，然后又变回 A。如果你的算法仅仅是检查值是否仍然是 A，那么它可能会错误地认为没有发生变化，从而导致逻辑错误。解决办法通常是引入一个版本号或标记，每次修改时也原子地更新版本号。不适合保护复杂数据结构：
std::atomic
适用于单个、简单的数据类型。它无法直接保护像链表、树、队列等复杂数据结构。对这些结构的修改通常涉及多个步骤（如修改指针、更新计数、分配/释放内存），这些步骤需要作为一个整体进行保护，这通常需要
std::mutex
或更复杂的无锁算法设计。性能错觉： 尽管
std::atomic
提供了无锁操作，但在高竞争环境下，反复的
compare_exchange
失败循环（自旋）可能会导致CPU资源浪费，甚至比使用互斥锁的性能更差。无锁不等于无开销。
最佳实践：
从小处着手，保持简单： 优先将
std::atomic
用于最简单的场景，例如计数器、布尔标志、单点指针等。只有当这些简单场景能够被原子操作完全覆盖时，才考虑使用它。默认使用
std::memory_order_seq_cst
： 这是最安全的起点。除非你对内存模型有深刻理解，并且有明确的性能瓶颈需要优化，否则不要轻易尝试更弱的内存序。正确性永远是第一位的。理解
compare_exchange
的语义： 这是构建无锁算法的核心。务必清楚
compare_exchange_weak
可能因为假失败而需要循环重试，而
compare_exchange_strong
则保证只有在值真正不匹配时才失败。结合其他同步原语：
std::atomic
并非万能。在许多情况下，它需要与
std::mutex
、
std::condition_variable
甚至
std::latch
/
std::barrier
等其他同步原语协同工作，以构建健壮的并发程序。充分测试并发代码： 并发bug往往难以复现和调试。务必编写严格的并发测试，利用不同的线程数量、运行环境，甚至使用专门的并发测试工具（如 ThreadSanitizer），以发现潜在的数据竞争和死锁。文档化内存序选择： 如果你使用了非默认的内存序，请务必在代码中详细注释，解释为什么选择这种内存序，它保证了什么，以及它不保证什么。这对于代码的维护和后续调试至关重要。
总而言之，
std::atomic
是C++并发编程工具箱中的一把利器，它赋予了我们直接与硬件内存模型交互的能力，从而实现高性能的无锁编程。但伴随这种能力而来的，是对并发模型更深层次的理解和更严谨的设计。用得好，性能飞跃；用不好，bug缠身。
以上就是C++如何使用std::atomic保证线程安全的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/1476108.html
微信扫一扫 
支付宝扫一扫 
