1. 项目概述为什么原子操作是C并发编程的基石在C多线程编程的世界里我们常常会遇到一个看似简单却暗藏玄机的问题两个线程同时对一个共享的整数变量进行自增操作最终结果会是多少如果你没有使用任何同步机制结果很可能不是你预期的“自增两次”。这个经典问题直接引出了并发编程的核心挑战——数据竞争。而原子操作正是C标准库为我们提供的用于解决这类问题最基础、最高效的武器之一。它不是简单的锁而是一种硬件级别的保证确保某个操作在执行过程中不会被其他线程的操作打断从而在多核处理器上实现安全、高效的并发访问。简单来说原子操作就是“不可分割”的操作。想象一下你在银行柜台存钱这个“存钱”动作对银行系统来说要么完全成功钱数增加、记录更新要么完全失败一切回滚绝不会出现“钱数增加了但记录没更新”这种中间状态。原子操作之于内存数据就如同这个“存钱”事务之于银行系统。在C11之前实现这样的操作需要依赖平台特定的内联汇编或编译器内置函数既繁琐又容易出错。C11将原子操作纳入了标准库atomic头文件为编写可移植的高性能并发程序奠定了坚实的基础。对于任何涉及C并发编程的开发者无论是开发高性能服务器、游戏引擎还是嵌入式实时系统理解并熟练运用原子操作都是绕不开的课题。它不仅是实现无锁数据结构的基础也是理解内存序、构建正确并发模型的关键入口。接下来我将带你深入原子操作的内部从基础使用到内存模型再到实战避坑为你构建一套完整的知识体系。2. 原子操作的核心概念与类型解析2.1 什么操作是“原子”的要理解原子操作首先要明白什么操作在并发环境下是“非原子”的。以最常见的i自增操作为例在底层它通常包含三个步骤从内存将变量i的值加载到CPU寄存器。在寄存器中对值进行加一计算。将计算结果写回i所在的内存地址。在多线程环境下如果两个线程几乎同时执行i且i初始值为0可能会发生如下交错执行线程A执行步骤1读到i0。线程B执行步骤1也读到i0。线程A执行步骤2和3将1写回内存。线程B执行步骤2和3同样将1写回内存。 最终i的结果是1而不是预期的2。这就是数据竞争导致的错误。原子操作例如std::atomicint::fetch_add通过硬件指令如x86的LOCK XADD将这三个步骤“捆绑”成一个不可分割的整体。在执行这个整体操作期间CPU会确保其他核心无法访问该内存地址从而避免了上述交错保证了结果的正确性。2.2 C标准库中的原子类型Catomic头文件提供了两种主要的原子类型模板特化模板类型对于所有基本的整数类型如int,long,char和指针类型标准库提供了特化版本如std::atomicint,std::atomiclong*。这些特化类型支持丰富的原子算术和逻辑操作。通用模板类型std::atomicT可以用于任何满足“可平凡复制”条件的自定义类型。但对于自定义类型通常只支持load,store,exchange,compare_exchange_strong/weak等基本操作不直接支持算术运算。常用原子整数类型操作示例#include atomic #include iostream #include thread std::atomicint counter(0); // 初始化原子计数器为0 void increment() { for (int i 0; i 100000; i) { // 以下三种方式都是原子的自增操作 // 1. 使用成员函数 counter.fetch_add(1, std::memory_order_relaxed); // 2. 使用重载运算符等价于fetch_add // counter; // 3. 使用复合赋值等价于fetch_add // counter 1; } } int main() { std::thread t1(increment); std::thread t2(increment); t1.join(); t2.join(); // 结果一定是 200000 std::cout Final counter value: counter.load() std::endl; return 0; }注意counter、counter 1和counter.fetch_add(1)在效果上都是原子的但它们的返回值语义略有不同。前两者返回操作后的新值而fetch_add返回操作前的旧值。根据你的场景选择最合适的接口。2.3 原子操作与互斥锁的性能对比很多初学者会问既然有互斥锁std::mutex可以保护共享数据为什么还需要原子操作核心答案在于性能。互斥锁是一种“重量级”的同步机制。当线程尝试获取一个已被锁定的互斥锁时它可能会被操作系统挂起进入睡眠状态等待锁被释放后再被唤醒。这个上下文切换的开销是巨大的通常在微秒级别。原子操作则是一种“轻量级”的机制它利用CPU提供的原子指令直接在硬件层面完成。在无激烈竞争即多个线程不会频繁地争抢同一个原子变量的情况下原子操作的性能开销接近于普通的读写操作纳秒级别。我们可以做一个简单的性能测试对比#include atomic #include mutex #include chrono #include iostream #include vector #include thread const int num_iterations 1000000; const int num_threads 4; // 测试1使用互斥锁 void test_with_mutex() { int counter 0; std::mutex mtx; auto start std::chrono::high_resolution_clock::now(); std::vectorstd::thread threads; for (int i 0; i num_threads; i) { threads.emplace_back([]() { for (int j 0; j num_iterations; j) { std::lock_guardstd::mutex lock(mtx); counter; } }); } for (auto t : threads) t.join(); auto end std::chrono::high_resolution_clock::now(); auto duration std::chrono::duration_caststd::chrono::milliseconds(end - start); std::cout Mutex: duration.count() ms, counter counter std::endl; } // 测试2使用原子操作 void test_with_atomic() { std::atomicint counter(0); auto start std::chrono::high_resolution_clock::now(); std::vectorstd::thread threads; for (int i 0; i num_threads; i) { threads.emplace_back([]() { for (int j 0; j num_iterations; j) { counter.fetch_add(1, std::memory_order_relaxed); } }); } for (auto t : threads) t.join(); auto end std::chrono::high_resolution_clock::now(); auto duration std::chrono::duration_caststd::chrono::milliseconds(end - start); std::cout Atomic: duration.count() ms, counter counter.load() std::endl; } int main() { test_with_mutex(); test_with_atomic(); return 0; }在我的测试环境4核CPU上原子操作的版本通常比互斥锁版本快一个数量级以上。这清晰地展示了在细粒度计数器、状态标志等场景下原子操作无可替代的性能优势。3. 深入内存序原子操作的正确性保障如果你认为使用了原子操作就万事大吉那很可能掉入一个更隐蔽的陷阱。原子操作保证了单个变量的操作原子性但并没有自动解决多个变量或单个变量多次操作之间的顺序可见性问题。这就是std::memory_order出场的时候。它是理解C并发编程深水区的关键也是区分普通使用者和高手的分水岭。3.1 为什么需要内存序现代CPU和编译器为了提升性能会进行大量的优化包括指令重排编译器或CPU可能会在不改变单线程执行结果的前提下重新排列指令的执行顺序。缓存层级每个CPU核心有自己的缓存修改数据时不会立即同步到主内存或其他核心的缓存。考虑一个经典的“发布-订阅”场景// 线程A (发布者) data 42; // 1. 初始化数据 data_ready.store(true); // 2. 发布就绪标志 // 线程B (订阅者) if (data_ready.load()) { // 3. 检查标志 std::cout data; // 4. 使用数据 }如果data不是原子变量且没有正确设置内存序那么在线程A中编译器或CPU可能会将步骤1和2重排因为它们在单线程内没有依赖关系。导致线程B可能看到data_ready为true但读到的data却是未初始化的垃圾值因为步骤1的写入尚未对其他线程可见。3.2 六种内存序详解C定义了六种内存序从最宽松到最严格赋予了开发者对性能与正确性进行精细权衡的能力。内存序含义典型用途性能开销memory_order_relaxed只保证原子性不保证顺序。不同线程看到的操作顺序可能任意交错。简单的计数器、统计量不用于同步。最低memory_order_consume已不推荐使用作用类似acquire但仅限数据依赖的操作。历史遗留新代码应避免。-memory_order_acquire读操作。保证本线程中所有后续的读/写操作不会被重排到该读操作之前。load操作用于获取“锁”或读取同步标志。中等memory_order_release写操作。保证本线程中所有之前的读/写操作不会被重排到该写操作之后。store操作用于释放“锁”或发布同步标志。中等memory_order_acq_rel读-修改-写操作。同时具有acquire和release的语义。fetch_add,exchange,compare_exchange等RMW操作。较高memory_order_seq_cst顺序一致性。默认内存序。保证所有线程看到的操作顺序一致且所有操作全局有序。需要最强保证的场景或当你对内存序不确定时。最高3.3 实战中的内存序配对模式理解理论后最关键的是掌握实践中的固定搭配模式。模式一Release-Acquire 配对最常用用于在线程间传递“保护性”数据。一个线程通过release写发布数据另一个线程通过acquire读来获取数据并确保能看到release写之前的所有写入。std::atomicbool flag{false}; int payload 0; // 非原子数据 // 线程A: 发布者 payload 42; // 1. 准备数据 flag.store(true, std::memory_order_release); // 2. 发布release保证步骤1不会重排到2之后 // 线程B: 订阅者 while (!flag.load(std::memory_order_acquire)) { // 3. 获取acquire保证步骤4不会重排到3之前 // 忙等待或休眠 } std::cout payload; // 4. 安全读取这里一定能看到42模式二Release-Consume 配对已过时了解即可C17后不鼓励使用因为其语义复杂且编译器实现困难。它只保证有数据依赖关系的操作顺序不如acquire直观安全。模式三Sequentially Consistent (seq_cst)这是所有原子操作的默认内存序。它提供了最简单的编程模型但代价是性能最低。在你刚开始接触并发或者逻辑极其复杂需要最强保证时使用。std::atomicint x{0}, y{0}; // 线程A x.store(1, std::memory_order_seq_cst); // #1 // 线程B y.store(1, std::memory_order_seq_cst); // #2 // 线程C int r1 x.load(std::memory_order_seq_cst); // #3 int r2 y.load(std::memory_order_seq_cst); // #4 // 线程D int r3 y.load(std::memory_order_seq_cst); // #5 int r4 x.load(std::memory_order_seq_cst); // #6 // 在seq_cst下不可能出现 r11, r20 且 r31, r40 的情况。 // 因为所有操作有一个全局一致的总顺序。模式四Relaxed 计数与标志当操作的顺序不重要只需要原子性时使用。比如一个简单的进度计数器。std::atomicint progress_counter{0}; void worker() { // 做一些工作... progress_counter.fetch_add(1, std::memory_order_relaxed); // 其他线程读取progress_counter时可能看到任意中间值但这对于进度显示来说是可以接受的。 }实操心得我的经验法则是80%的场景使用release-acquire配对它能解决绝大多数同步问题且性能优于seq_cst。15%的场景使用relaxed用于独立的计数器或状态位。只有5%的场景或初期原型阶段使用默认的seq_cst。永远不要使用consume。4. 高级原子操作与无锁编程初探掌握了基础的原子读写和内存序我们就可以探索更强大的原子操作它们是构建无锁数据结构的基石。4.1 比较并交换compare_exchange_strong/weak这是原子操作库中最强大、最复杂的操作缩写为CAS。它的语义是“如果原子变量的当前值等于预期值则将其交换为新值否则用当前值更新预期值。”bool compare_exchange_strong(T expected, T desired, std::memory_order success, std::memory_order failure) noexcept;expected传入一个期望值。函数会将其与原子变量的实际值比较。desired如果比较相等希望设置的新值。success如果交换成功使用的内存序。failure如果交换失败使用的内存序。这个内存序不能比success更强。strong与weak的区别compare_exchange_strong保证严格符合上述语义。即使在某些平台上如LL/SC架构可能因为虚假失败而需要循环它也会在内部处理好对外表现为“强”语义。compare_exchange_weak允许虚假失败。即即使原子变量的值等于expected操作也可能失败返回false并且不修改expected。这通常发生在某些CPU架构上。因此weak版本必须用在循环中。何时用哪个如果你打算自己写循环重试用weak。它可能比strong在x86等平台上有轻微的性能优势因为少了一次条件判断。如果你希望操作“一锤定音”或者不想自己处理循环用strong。在x86架构上两者性能几乎没有差别。在ARM/PowerPC等弱内存模型架构上weak可能更高效。4.2 一个无锁栈的简单示例让我们用CAS实现一个最简单的无锁栈单生产者单消费者场景下安全感受一下无锁编程的思维模式。#include atomic templatetypename T class LockFreeStack { private: struct Node { T data; Node* next; Node(const T d) : data(d), next(nullptr) {} }; std::atomicNode* head{nullptr}; public: void push(const T value) { Node* new_node new Node(value); new_node-next head.load(std::memory_order_relaxed); // 使用CAS循环直到成功将新节点设置为栈顶 while (!head.compare_exchange_weak(new_node-next, new_node, std::memory_order_release, std::memory_order_relaxed)) { // CAS失败说明new_node-next已经不是最新的head了 // compare_exchange_weak已经自动将new_node-next更新为最新的head。 // 继续循环重试。 } } bool pop(T value) { Node* old_head head.load(std::memory_order_relaxed); if (old_head nullptr) { return false; // 栈为空 } // 尝试将head指向下一个节点 while (!head.compare_exchange_weak(old_head, old_head-next, std::memory_order_acquire, std::memory_order_relaxed)) { if (old_head nullptr) { return false; // 在重试过程中栈变空了 } } value old_head-data; delete old_head; // 注意这里存在“ABA问题”下文会讲 return true; } };这个栈的push操作是经典的“读-改-写”循环模式。pop操作也类似但多了一个空栈检查。注意这里的内存序选择push中的CAS成功时用release发布新节点确保新节点内容对其他线程可见。pop中的CAS成功时用acquire获取被弹出的节点确保能读到该节点完整的数据。4.3 无锁编程的著名陷阱ABA问题上面pop函数中的delete操作隐藏了一个重大风险——ABA问题。线程1执行pop读取old_head AA-next B。线程1在CAS之前被挂起。线程2执行pop成功弹出A并delete A。线程3执行push分配了一块新内存地址恰好也是A因为内存被重用并将它推入栈中新节点的next指向C。线程1恢复执行它的CAS操作head.compare_exchange_weak(A, B)会成功因为head此刻又指向了A虽然是一个全新的节点。这导致栈顶被错误地设置为B而新节点A以及它后面的C丢失了并且线程1会错误地删除这个新的A节点导致未定义行为。解决ABA问题的常见方法垃圾回收像Java、Go那样有GC的语言天然避免此问题。风险指针线程在访问一个可能被其他线程释放的节点时会用一个“风险指针”来保护它防止其被物理删除。引用计数使用带引用计数的智能指针如std::shared_ptr管理节点。但std::shared_ptr的原子操作本身开销很大。序号标记在指针的高位附加一个递增的序号Tag。每次修改指针序号加1。这样即使地址复用序号也不同CAS会失败。这是最常用的无锁数据结构实现技巧。注意事项无锁编程极其复杂且容易出错。除非你是在编写基础库如libc、folly或对性能有极端要求否则优先考虑使用成熟的并发数据结构如moodycamel::ConcurrentQueue或简单的互斥锁。自己实现无锁数据结构是高级专家领域需要严格的正确性证明和测试。5. 原子操作实战性能计数器与状态机设计理论说再多不如看实战。原子操作最常见的两个应用场景就是高性能计数器或统计指标和轻量级状态机。5.1 设计一个高性能多线程计数器假设我们要为一个HTTP服务器统计每秒的请求数QPS。多个工作线程会并发地增加计数器一个单独的监控线程会定期如每秒读取并重置计数器。#include atomic #include iostream #include thread #include chrono #include vector class QPSCounter { private: // 使用无符号64位整数防止溢出在可预见的未来不会溢出 alignas(64) std::atomicuint64_t counter_{0}; // alignas(64) 避免伪共享 alignas(64) std::atomicbool stop_{false}; public: void increment() { // 使用relaxed内存序因为只需要原子性不涉及与其他数据的同步。 counter_.fetch_add(1, std::memory_order_relaxed); } uint64_t fetch_and_reset() { // 使用seq_cst因为这是一个“读-改-写”操作且需要与increment操作有明确的全局顺序。 // 也可以使用memory_order_acq_rel但seq_cst更安全直观。 return counter_.exchange(0, std::memory_order_seq_cst); } void stop() { stop_.store(true, std::memory_order_relaxed); } bool stopped() const { return stop_.load(std::memory_order_relaxed); } }; void worker(QPSCounter counter, int id) { while (!counter.stopped()) { // 模拟处理请求 std::this_thread::sleep_for(std::chrono::milliseconds(10)); counter.increment(); // std::cout Worker id incremented.\n; } } void monitor(QPSCounter counter) { using namespace std::chrono; auto last_time steady_clock::now(); while (!counter.stopped()) { std::this_thread::sleep_for(std::chrono::seconds(1)); auto now steady_clock::now(); auto elapsed duration_castseconds(now - last_time); last_time now; uint64_t count counter.fetch_and_reset(); double qps static_castdouble(count) / elapsed.count(); std::cout QPS: qps ( count requests in last second)\n; } } int main() { QPSCounter counter; const int num_workers 8; std::vectorstd::thread workers; for (int i 0; i num_workers; i) { workers.emplace_back(worker, std::ref(counter), i); } std::thread monitor_thread(monitor, std::ref(counter)); // 运行10秒 std::this_thread::sleep_for(std::chrono::seconds(10)); counter.stop(); for (auto t : workers) t.join(); monitor_thread.join(); return 0; }设计要点alignas(64)这是为了避免伪共享。现代CPU缓存以缓存行通常64字节为单位。如果两个频繁写的原子变量位于同一个缓存行一个CPU核心的写入会导致其他核心的整个缓存行失效引发不必要的缓存同步严重损害性能。将它们对齐到不同的缓存行可以极大提升并发性能。内存序选择increment用relaxed因为每个请求计数是独立的。fetch_and_reset用seq_cst确保在重置的瞬间能获取到之前所有increment的完整计数不会漏掉或重复计数。停止标志使用一个独立的原子布尔量作为停止信号内存序relaxed即可因为它的读写与其他数据没有顺序依赖。5.2 实现一个无锁状态机状态机是另一个典型场景。例如一个连接可能有Disconnected、Connecting、Connected、Disconnecting几种状态。使用原子操作可以避免在状态转换时加锁。#include atomic #include iostream #include thread #include cassert enum class ConnectionState { Disconnected, Connecting, Connected, Disconnecting }; class Connection { private: std::atomicConnectionState state_{ConnectionState::Disconnected}; public: bool try_connect() { ConnectionState expected ConnectionState::Disconnected; // 只有当前状态是Disconnected时才尝试转换为Connecting if (state_.compare_exchange_strong(expected, ConnectionState::Connecting, std::memory_order_acq_rel, std::memory_order_acquire)) { // 模拟连接过程 std::this_thread::sleep_for(std::chrono::milliseconds(50)); // 连接成功状态转为Connected state_.store(ConnectionState::Connected, std::memory_order_release); std::cout Connected successfully.\n; return true; } else { std::cout Cannot connect, current state is not Disconnected.\n; return false; } } void disconnect() { ConnectionState old_state state_.load(std::memory_order_acquire); if (old_state ConnectionState::Disconnected) { std::cout Already disconnected.\n; return; } // 尝试将状态从Connected或Connecting转为Disconnecting // 注意这里需要处理Connecting状态可能连接尚未成功 ConnectionState expected ConnectionState::Connected; if (state_.compare_exchange_strong(expected, ConnectionState::Disconnecting, std::memory_order_acq_rel, std::memory_order_acquire)) { // 模拟断开过程 std::this_thread::sleep_for(std::chrono::milliseconds(30)); state_.store(ConnectionState::Disconnected, std::memory_order_release); std::cout Disconnected successfully.\n; } else if (old_state ConnectionState::Connecting) { // 如果正在连接我们可以选择等待或直接失败 std::cout Cannot disconnect while connecting.\n; } } ConnectionState get_state() const { return state_.load(std::memory_order_acquire); } };关键点分析CAS保证状态转换的原子性try_connect使用CAS确保“从断开到连接中”这个转换是原子的防止多个线程同时发起连接。内存序的配对compare_exchange_strong成功时使用acq_rel因为它是一个读-修改-写操作既需要获取之前状态acquire语义也需要发布新状态release语义。失败时使用acquire因为我们需要读取当前最新的状态值。store和load简单的状态设置和读取使用release和acquire配对确保状态变更对其他线程可见。状态机逻辑的完整性这个示例是简化的真实的状态机可能需要处理更多边界情况比如超时、失败重试等。6. 常见陷阱、调试技巧与性能调优即使理解了所有概念在实际使用原子操作时依然会踩到很多坑。这里分享一些我积累的经验和教训。6.1 常见陷阱与错误用法陷阱一误用memory_order_relaxed导致同步错误这是最常见的错误。把relaxed用在了需要同步的地方。// 错误示例 std::atomicbool ready{false}; int data 0; // 线程A data 42; ready.store(true, std::memory_order_relaxed); // 错误其他线程可能先看到readytrue后看到data42 // 线程B while (!ready.load(std::memory_order_relaxed)) {} // 错误 std::cout data; // 可能打印出0修正必须使用release-acquire配对。陷阱二认为原子操作万能滥用导致性能下降原子操作不是免费的午餐。在x86上一个seq_cst的store操作可能比普通的store慢一个数量级。更糟糕的是频繁写入的原子变量会导致缓存行在多个CPU核心间“乒乓”严重消耗总线带宽。// 可能性能不佳的示例每个线程频繁更新自己的“最后活动时间” struct ThreadData { alignas(64) std::atomicstd::chrono::steady_clock::time_point last_active; };如果这个last_active被频繁更新比如微秒级即使有缓存行对齐也会产生大量缓存一致性流量。对于这种场景可以考虑使用线程本地存储定期批量同步。陷阱三错误处理ABA问题如前所述在无锁链表中直接delete节点会导致ABA问题。必须使用带标签指针或风险指针等技术。陷阱四原子操作与普通操作混用原子操作只保证自身的原子性。如果一个数据结构中部分成员是原子的部分不是并且它们之间存在逻辑关联那么你仍然需要额外的同步如互斥锁来保护这个逻辑整体。struct Config { std::atomicbool updated{false}; int value1; double value2; // value1和value2不是原子的 }; // 线程A更新配置 config.value1 100; config.value2 3.14; config.updated.store(true, std::memory_order_release); // 仅保证updated的发布顺序 // 线程B读取配置 if (config.updated.load(std::memory_order_acquire)) { // 这里能保证看到updatedtrue但不能保证看到的value1和value2是线程A设置的那一对 // 可能看到新的value1和旧的value2或者反之。 use(config.value1, config.value2); }修正要么将整个Config对象用锁保护要么将value1和value2也做成原子变量如果类型支持并使用memory_order_release/acquire来同步它们。6.2 调试与验证技巧并发Bug难以复现调试困难。以下是一些有用的方法使用std::atomic的is_lock_free成员函数在运行时检查该原子类型是否真的是无锁实现由CPU原子指令支持。如果不是std::atomic可能会使用内部锁来模拟原子性这可能会引入死锁风险虽然标准库会尽力避免。std::atomicint a; if (a.is_lock_free()) { std::cout atomicint is lock-free on this platform.\n; } else { std::cout atomicint uses a mutex internally.\n; }借助ThreadSanitizer在GCC/Clang中编译时添加-fsanitizethread选项。它能在运行时检测数据竞争、死锁等并发错误。这是发现原子操作使用不当如缺少同步的最强大工具。使用模型检查工具对于核心的无锁算法可以考虑使用像CDSChecker或herd这样的弱内存模型检查工具它们能系统地遍历所有可能的内存操作交错顺序验证你的算法是否正确。压力测试与随机调度编写多线程测试用例并利用std::async或线程池进行大量重复测试。可以在代码中插入随机休眠(std::this_thread::sleep_for)来增加线程交错的随机性更容易暴露问题。6.3 性能调优建议测量而不是猜测任何性能优化都必须基于 profiling性能剖析。使用perf、vtune等工具查看原子操作指令如LOCK前缀指令的占比和缓存未命中率。减少共享最好的优化是消除共享。能使用线程本地变量就不要用全局原子变量。对齐以避免伪共享对于高频写入的原子变量使用alignas(64)或C17的std::hardware_destructive_interference_size来确保它们位于不同的缓存行。选择合适的内存序在保证正确性的前提下使用最宽松的内存序。将默认的seq_cst替换为release-acquire或relaxed通常能带来可观的性能提升尤其是在ARM等弱内存模型架构上。批量操作如果可能将多次原子更新合并为一次。例如每个线程先将计数累加到一个本地变量每隔一段时间再一次性加到全局原子计数器上。考虑无锁数据结构的替代品有时一个设计良好的、基于锁的并发数据结构由于其更简单的逻辑和更少的缓存行竞争实际性能可能优于一个复杂的无锁实现。不要盲目追求“无锁”。在我个人的经验里原子操作就像一把锋利的手术刀用对了可以精准高效地解决并发问题用错了则会伤及自身。它要求开发者对硬件、编译器和语言标准有更深的理解。从seq_cst开始确保正确性然后通过perf工具分析热点再尝试逐步放宽内存序进行优化是一个稳妥的实践路径。最后记住那句老话“如果可能避免共享如果必须共享优先考虑加锁只有当锁成为确凿的性能瓶颈时才考虑无锁编程。”对于绝大多数应用场景一个高效的读写锁std::shared_mutex往往比复杂的无锁结构更合适。