无锁编程与原子操作：从内存序到高性能并发实践

1. 为什么我劝你先别急着上锁：无锁编程到底解决什么问题

凡是写过两年以上并发代码的人，迟早会碰见这样一个场景：某个热点变量被几十个线程疯狂读写，你用 std::mutex 保护它是没错，但性能就是上不去。你用 perf 一看，光等锁就烧掉了 40% 的 CPU 时间片。这时候你大概率会开始琢磨无锁编程——也就是标题里那个听着很酷、用起来很烫手的领域。

先说清楚无锁编程（lock-free programming）到底在解决什么问题。传统加锁方案的核心矛盾是，锁把“保护数据”和“阻塞线程”绑在了一起。一旦线程在临界区里被切换出去，或者发生锁竞争，其他线程就得进入睡眠-唤醒的调度流程，这里面的开销包括系统调用、上下文切换、缓存失效，一套走下来几十微秒就没了。而现代 CPU 一个 CAS 指令（Compare-And-Swap）也就是几个纳秒的事。所以无锁编程的核心思路就一句话：用原子操作代替锁来协调共享数据的访问，把“可能阻塞的等待”变成“不会阻塞的重试”。

但这里必须泼一盆冷水。无锁编程不是银弹，它解决的是“锁竞争激烈、临界区极短”这个特定场景。如果你的临界区本来就很长，比如里面要做磁盘 IO 或者复杂的计算，无锁方案并不会让你起飞，反而会让代码复杂度成倍上升。我见过不少团队把简单的生产消费队列强行改成无锁版本，结果线上 Bug 一个接一个，最后又灰溜溜改回带锁。真正适合无锁的场景通常是：共享计数器、指针发布、高频状态标志、简单数据结构的并发读写，一句话总结就是“操作极短、频率极高、竞争不可控”。

另一个需要提前建立的认知是，无锁意味着用“自旋重试”代替“阻塞等待”。多线程同时抢一个资源时，赢家直接改完走人，输家立刻循环重试，而不是被内核挂起。这套机制在高竞争下可能造成 CPU 空转，但在低竞争或中等竞争下，比起锁的上下文切换开销，无锁通常能赢得非常明显。

这篇文章会围绕“无锁编程与原子操作”尽量讲透两层东西。第一层是语言层面，std::atomic 的接口、内存序（memory order）的语义，以及不同内存序在编译器层面和 CPU 层面的真实代价。第二层是工程层面，怎么从零搭建一个可用的无锁栈，会遇到哪些坑（ABA、内存回收、假共享），以及我实测下来的一些结论。

顺带回答一下搜索热词里的那个问题：C++11 的内存序是专门为原子操作准备的吗？ 结论是不完全是。内存序是内存模型（memory model）的一部分，它通过原子操作这把钥匙暴露给程序员，但它约束的对象并不仅仅是原子操作本身，还包括原子操作周围的普通内存访问。后面我会专门用一整章来讲清楚这个关系，这里先不剧透太多。

2. 锁的代价到底有多大：从“不进临界区的等待”说起

2.1 一次互斥锁等待到底慢在哪里

很多人对锁的性能问题没有体感，觉得 std::mutex 的 lock 不就是几条指令吗？实际远没有那么简单。当一个线程拿不到锁时，在 Linux 上，pthread_mutex_lock 会先尝试几次自旋（取决于 glibc 的配置），失败后调用 futex 系统调用进入睡眠，这个路径包含了用户态到内核态的切换、线程状态变更、红黑树操作、调度器重新分配 CPU，等到持锁线程 unlock 时还得再次唤醒等待的线程。一来一回两个完整的上下文切换，在现在的硬件上大概需要 2 到 5 微秒。

如果锁竞争率为 30%，每个事务只持锁 100 纳秒，那么平均每次操作可能摊上几百纳秒的调度开销，这个数字对于高频交易、游戏服务器、数据库引擎来说已经非常刺眼了。更阴间的是锁竞争带来的优先级反转和死锁风险，这类问题不会稳定复现，一旦出现在生产环境就是灾难。

再往底层说，锁的语义天然要求“独占”和“互斥”，这会让 CPU 的缓存行失效。线程 A 修改了共享变量并释放锁，线程 B 拿到锁后去读变量，发现缓存行已经被标记为 invalid，只能重新从内存或者通过缓存一致性协议拉取。这个代价叫 cache miss，一次主内存访问大约是几十纳秒。锁加上缓存失效再加上上下文切换，就是对性能的“三连击”。

2.2 原子操作为什么能绕过锁

原子操作的底层不是“不锁”，而是把锁的粒度压缩到了硬件指令级别。在 x86 上，std::atomic 的很多操作会落到 lock cmpxchg、lock xadd 这样的指令，lock 前缀会锁住系统总线或缓存行，保证指令在执行期间不会被其他核打断。在 ARM 上则是用 LL/SC（Load-Linked / Store-Conditional）指令对来实现。

这类指令不会让线程睡眠，也不会触发系统调用，执行完要么成功要么失败，失败了你就在用户态立刻重试。所以从效果上看，一个原子操作替代的是“加锁-读-改-写-解锁”整条路径，而代价只有一条指令或一个短循环。

2.3 无锁编程适用场景自检清单

在决定要不要上无锁方案之前，我建议你先过一遍这个清单：

• 临界区代码是否只有几条指令？如果临界区里有堆分配、加锁嵌套、系统调用，无锁很难有优势。
• 共享数据的并发读多写少还是写多？读多写少可以用原子读代替整把锁；写多的情况要仔细衡量 CAS 竞争。
• 能不能接受代码复杂度上升？无锁代码的调试难度远高于带锁代码，团队里至少要有一两个能 hold 住的人。
• 有没有现成的无锁库可以复用？比如 moodycamel::ConcurrentQueue、boost::lockfree，先看库再看自己造轮子。

从我的实践来看，无锁最舒服的使用方式不是“全套无锁”，而是“把锁粒度缩小到原子级别”。比如以前你用 mutex 保护一个计数器，现在改成 std::atomic<int> 直接自增；以前你用条件变量等一个状态翻转，现在改成 std::atomic<bool> 配合自旋等待。这种微改造又稳又见效，比一上来就手写无锁队列靠谱得多。

3. 原子操作：从硬件指令到 C++ 接口的完整映射

3.1 一条 CAS 指令到底做了什么

先看 C++ 里最常用的 CAS 接口，它的签名长这样：

cpp复制bool compare_exchange_weak(T& expected, T desired,
                           std::memory_order success,
                           std::memory_order failure);

语义是：比较原子变量的当前值是否等于 expected，如果相等，就把它替换成 desired，返回 true；如果不相等，把 expected 更新成当前值，返回 false。这个“比较-交换”的过程在硬件层面是一个不可分割的序列。

在 x86 上，compare_exchange_weak 对应的是 lock cmpxchg。cmpxchg 指令会隐式比较 eax（也就是 expected）和内存操作数，相等则写入新值。前面的 lock 前缀把这个比较-写入的执行变成原子的，其他核心的读写在它执行期间会被阻塞或者需要绕路。

为什么接口里同时有 weak 和 strong 两个版本？这要从 ARM 的 LL/SC 说起。LL（Load-Linked）负责从内存读取一个值并打上监视标记，SC（Store-Conditional）负责写入，但如果在这个期间有任意其他写入触碰了该地址，或者发生中断、缓存行替换，SC 会失败。也就是说 ARM 上的 CAS 是“可能失败，但失败不一定代表值被改过”，这种失败叫“假失败”（spurious failure）。compare_exchange_weak 允许这种假失败，适合放在循环里重试；compare_exchange_strong 则保证失败必定是因为值不匹配，虽然更“可靠”，但在 ARM 上可能要多做一层循环来消除假失败。

实际写循环的时候，我会优先用 weak 版本，配合循环天然就正确。如果是一次性尝试（不循环），那才需要考虑 strong。

3.2 除了 CAS，还有哪些实用原子接口

CAS 是万金油，但有些场景用更专门的指令性能更好。

fetch_add 对应 x86 的 lock xadd，它返回旧值的同时完成加操作，用于计数器、序列号生成非常合适。一个 std::atomic<int> counter{0}; counter.fetch_add(1); 比用 CAS 循环去模拟加法快很多，因为 CAS 循环每次都要把 expected 重新 load，生成一个 load + cmpxchg 的序列，而 xadd 一条指令就结束了。

exchange 用来原子地写入一个值并取回旧值，对应 x86 的 xchg。它比“读-算-写”的 CAS 循环要稳，比如实现一个自旋锁，就可以用 flag.exchange(true) 判断是否拿锁。

load 和 store 是原子的读与写，听上去简单，但在后面的内存序语境里大有讲究。默认情况下它们都是 memory_order_seq_cst，保证“顺序一致性”，也就是全局只有一个操作序，所有线程看到的状态变更顺序一致。这个语义最强但也最贵。

3.3 std::atomic 对类型的限制

std::atomic 本身使用起来很方便，但它要求类型必须是 trivially copyable。也就是不能用 std::vector、std::string 这些带动态资源的类型去做原子操作，因为原子操作在底层直接按字节复制，容器的拷贝构造函数和析构函数不会在原子路径里被调用，一旦用了，轻则逻辑错误，重则内存泄漏。

对于小于等于指针宽度的整数类型，std::atomic 通常是 lock-free 的，也就是真正映射到硬件指令。但标准库也提供 is_lock_free() 接口让你运行时检查。我的习惯是每个关键原子类型都在启动时断言一下 is_lock_free()，避免开发机上飞起，上线后某个平台突然退化成内部锁。

3.4 从硬件角度看原子操作的代价

原子操作不是零成本的。在 x86 上，lock 前缀会让缓存行在操作期间被锁住，其他核心访问同一个缓存行时会被强制等待，这导致原子操作的延迟通常是非原子读写的数倍。好消息是大多数操作在 L1 缓存命中的前提下仍然只有几十纳秒，远低于锁的调度开销。

真正的开销大头在后面：当你用原子操作修改变量后，其他核的缓存行会失效，下次读取会触发 cache miss。如果这个变量被多个线程同时高频访问，缓存行会在多个核之间来回传输，这种现象叫 cache line bouncing。极端情况下，一个简单的 fetch_add 可能因为缓存竞争比带锁还慢。所以无锁编程并不是无代价，它是用总线带宽和缓存一致性协议的资源换掉了操作系统的调度资源。

4. 内存序到底是干什么的：那个热词问题的完整答案

4.1 先回答热词：内存序专门为原子操作准备的？

先说结论：内存序不是为原子操作服务的，恰恰相反，内存序是内存模型暴露给程序员控制代码重排的工具，而原子操作只是它的载体。

C++11 之前，C++ 根本不承认多线程的存在。两个线程同时访问一个非原子变量就是未定义行为（UB），编译器可以按任意顺序重排指令，也可以在寄存器里缓存变量的副本而不写回内存。当年的多线程程序员只能靠 volatile、内嵌汇编和平台屏障函数硬生生拼出可用的并发代码，跨平台性极差。

C++11 引入了内存模型，核心思想是给“线程间数据共享”建立规则。原子操作在这个模型里承担的角色是“锚点”，它可以让你以原子方式读写变量，并在过程中指定一个 memory_order 来约束其他普通内存操作的相对顺序。

所以准确说法是：内存序依赖原子操作的 API 来指定，但它约束的不是原子操作本身，而是整个线程视角下的内存操作顺序。举个例子，你用 memory_order_release 去 store 一个标志位，这个 release 不仅保证标志位本身的写入是原子的，还保证在这个 store 之前的所有普通写操作不能被重排到它之后。用 memory_order_acquire 去 load 同一个标志位，则保证在这个 load 之后的普通读操作不能被重排到它之前。这样两个线程通过一个原子变量，就建立了对一大片普通数据的 happens-before 关系。

这就是网上“内存序是专门为原子操作准备的”这个说法的误区所在。内存序的语义对象是一块内存区域的操作序，原子变量只是这把锁的钥匙孔。

4.2 为什么编译器和 CPU 要四处重排指令

要理解内存序，必须先理解乱序的必要性。现代 CPU 为了填满流水线，会对没有数据依赖的指令动态调整执行顺序。比如下面这段代码：

cpp复制a = 1;
b = 2;

如果 a 的地址在缓存里，b 的地址在主内存里，CPU 可能先执行 a=1 再执行 b=2，也可能选择反过来。从单线程视角看无所谓，因为最后两个变量都被写入了。但从另一核的视角看，它可能先看到 b=2，再看到 a=1，这就产生了“顺序倒挂”。

编译器也会做类似的事情。为了优化寄存器分配，编译器可以把某些读写从循环里提出来，或者把两个独立的写合并成一次。这些优化在单线程下完全安全，但在多线程共享内存时，会让不同线程对内存状态产生不一致的观察。

内存序就是用来给这些重排画红线的。你告诉编译器：这个原子写必须是 release，那么此前的普通写不能被它越过；这块原子读必须是 acquire，那么此后的普通读不能被它提前。

4.3 C++ 的六种内存序逐一拆解

C++11 定义了六种 std::memory_order 枚举值，我按使用频率从高到低给你逐个讲。

memory_order_seq_cst 是默认值，全称顺序一致序。它要求所有原子操作在全局有一个统一的全序，所有线程看到的历史顺序完全一致。这是最符合直觉的模型，也是性能最贵的模型。在 x86 上，seq_cst 的 store 通常需要额外加 mfence 或改成 xchg，比 release 的 store 要慢一个档位。

memory_order_relaxed 是最弱的约束，只保证操作本身的原子性，不提供任何顺序保证。它适合使用场景非常明确的计数器——比如统计一个“近似访问量”，多个线程各自 fetch_add(1, relaxed)，最终结果反正会接近真实值，不需要和其他内存操作做顺序绑定。

memory_order_release 和 memory_order_acquire 是配对使用的，它们是实现“发布-订阅”模式的基础。release 用于写侧：保证其前的所有内存写操作（包括非原子写和 relaxed 写）不会重排到 release store 之后。acquire 用于读侧：保证其后的所有内存读操作不会重排到 acquire load 之前。这就是经典的一对一同步，消费方通过 acquire load 看到生产方 release store 之前写入的所有数据。

memory_order_acq_rel 是 release 和 acquire 的合体，它同时约束了前后的读写，通常用于读-改-写操作，比如 CAS、fetch_add 这类。如果你既要发布新状态，又要消费旧状态，acq_rel 是最自然的选择。

memory_order_consume 是最特殊也最鸡肋的一个，它本意是提供比 acquire 更弱的“依赖链”同步，避免在传播指针时才真正需要的屏障被过度强化。但因为在实践中硬件和编译器都很难精确追踪依赖链，C++17 正式建议把 consume 升级为 acquire 语义。我的建议很简单：别用。

4.4 x86 和 ARM 的现实差异

这里就涉及到平台相关的实战知识了。x86 是一个强内存序（TSO）架构，它允许的重排种类非常有限。在 x86-64 上，StoreStore 重排和 LoadLoad 重排基本不会发生，LoadStore 重排也被禁止，唯一允许的重排是 StoreLoad——也就是 store 可能晚于后续的 load 被全局可见。所以你在 x86 上写 release/acquire，编译器大多数时候直接翻译成普通 mov，不需要额外屏障指令，开销几乎为零。只有 seq_cst 的 store 需要额外处理。

ARM 是弱内存序架构，CPU 比 x86 激进得多，几乎允许所有种类的重排。为了保证 release/acquire 语义，编译器必须在相应位置插入 dmb ish 等屏障指令。这意味着同一份无锁代码，在 x86 上跑得很欢，放到 ARM 上可能就变成逻辑错误，甚至性能瓶颈。

实际操作中，我的经验是：先用默认的 seq_cst 把功能跑对，再根据性能热点逐步降级为 acquire/release 或 relaxed，放到 ARM 上必须着重做压力测试。千万不要一上来就在所有地方套 relaxed，出问题的时候你根本不知道是内存序的锅还是自己逻辑的锅。

5. 从零写一个无锁栈：完整实现与内存序选择

5.1 Treiber 栈：无锁数据结构入门的经典案例

理论讲再多都不如一段能跑的代码。下面我用无锁栈（Treiber stack）作为例子，把前面提到的原子操作和内存序串起来。为什么选栈？因为它足够简单，同时又涵盖了 push/pop 两个核心方向，是无锁数据结构入门的必修课。

cpp复制#include <atomic>
#include <memory>

template <typename T>
class LockFreeStack {
private:
    struct Node {
        std::shared_ptr<T> data;
        Node* next;
        explicit Node(T const& value)
            : data(std::make_shared<T>(value)), next(nullptr) {}
    };

    std::atomic<Node*> head_{nullptr};

public:
    void push(T const& value) {
        Node* new_node = new Node(value);
        new_node->next = head_.load(std::memory_order_relaxed);

        while (!head_.compare_exchange_weak(
            new_node->next,
            new_node,
            std::memory_order_release,
            std::memory_order_relaxed)) {
            // 失败时 new_node->next 会被更新为最新 head，直接重试
        }
    }

    std::shared_ptr<T> pop() {
        Node* old_head = head_.load(std::memory_order_acquire);

        while (old_head &&
               !head_.compare_exchange_weak(
                   old_head,
                   old_head->next,
                   std::memory_order_acquire,
                   std::memory_order_relaxed)) {
            // 失败时 old_head 已被更新为最新 head，继续循环
        }

        if (!old_head) {
            return nullptr;
        }

        std::shared_ptr<T> result;
        result.swap(old_head->data);
        delete old_head;
        return result;
    }
};

这段代码的核心是 CAS 循环。push 时先读取当前 head，构造新节点指向它，然后尝试把新节点换成新的 head。如果期间有其他线程插队改了 head，CAS 失败，new_node->next 会被自动更新为最新的 head，于是循环重试。pop 同理，先取 head，再把 head 换成 next。

5.2 为什么 push 用 release、pop 用 acquire

这段代码里最关键的是 push 的 memory_order_release 和 pop 的 memory_order_acquire。

先看 push。push 在修改链表指针之前，要先构造 Node 并写入数据。如果这个 store 用 relaxed，其他线程在 acquire load head 之后，去读 Node::data 有可能读到的是旧数据或者未完成构造的数据。而用 release 后，new Node(value) 里对 data 的写操作被保证在 head 的 store 之前完成并全局可见。后通过 acquire load 拿到 head 的线程，就能安全地读 Node 里的 data。

再看 pop。pop 里的 acquire 保证的是：一旦观察到了某个 head 值，那么这个 head 之前所有由 push 线程写入的数据都已经可见。也就是说 acquire 与 push 的 release 形成配对，数据通过 head 指针完成“发布-订阅”式的传递。

这就是无锁编程中最重要的内存序使用模式：写侧 release，读侧 acquire，一写一读配对，数据在线程间流动。

5.3 这段教学代码有哪些坑不能带进生产

上面这段代码能跑，但并不是生产可用的，有几个非常严重的隐患。

第一个是内存回收问题。pop 里直接 delete old_head 是危险的：线程 A pop 出一个节点并开始 delete，线程 B 可能还拿着同一个节点的指针没读完，A 把这块内存还给系统后，B 再访问就是 use-after-free。这在锁版本里不可能发生，因为锁保护了整段临界区，但无锁代码没有全局锁来保佑你。

业界常用的解决方案有 hazard pointer 和 epoch-based reclamation。hazard pointer 的思路是：读线程在访问节点前，先把该指针发布到一个全局的“危险指针”列表里，写线程想 delete 节点前，先检查列表看有没有人还在用。epoch-based reclamation 则是把删除延迟到所有线程都退出当前一轮操作之后。两者各有取舍，实现复杂度都不低。

第二个是 ABA 问题。假设线程 A 读取 head 为节点 X，然后线程 B 连续执行了 pop(X) 和 push(X)，也就是把 X 先拿走又放回来。此时 A 的 CAS 发现 head 还是 X，比较成功，但它不知道链表中间已经被改过了。对于栈这种结构，ABA 会让 A 误以为链表没有变化，导致逻辑错误。常见的解法是给指针加上一个单调递增的版本号，CAS 时同时比较指针和版本号。

第三个是节点分配。代码里用了 new 来分配节点，这意味着每次 push 都有堆分配和释放的开销。在无锁代码里，堆分配器本身就带锁，这个锁很可能成为新的瓶颈。一套完整的无锁容器，通常会使用无锁内存池来管理节点，但这又进一步推高了实现复杂度。

第四个是 false sharing，这个后面单开一节细说。

5.4 如果全部用 seq_cst 会怎么样

很多初学者会把所有原子操作都写成默认的 seq_cst，理由是“省心，反正能跑”。确实能跑，而且逻辑上绝对正确。问题在于性能。

在 x86 平台上，seq_cst 的 store 需要额外处理 StoreLoad 的语义。GCC 和 Clang 的做法是把 seq_cst store 编译成 xchg，或者先用普通 store 再加 mfence。不管哪种，都比普通 mov 慢一个数量级。如果你的无锁数据结构一个操作里有多次原子写，seq_cst 和 release 的差距会非常明显。

我的实践原则是这样的：正确性优先的阶段全部用 seq_cst，等压力测试通过后，再用 perf 找出热点原子操作，逐个尝试降级为 acquire/release 或 relaxed，每降一次就跑一遍全部并发测试和 TSan。降级不是技术秀，是为了让代码在弱内存序的 ARM 上也能跑，同时减少不必要的屏障开销。

6. 常见问题与排查技巧实录：我踩过的无锁编程的坑

6.1 原子变量周围到底需不需要 volatile

这是无锁编程领域最经典的谣言之一。C++11 之后，std::atomic 自己已经拥有足够的“防重排、防合并、防寄存器缓存”能力，不需要也不应该再加 volatile。给原子变量加 volatile 不仅没有正面作用，还可能让编译器对某些优化束手束脚。

但这里有个特例：当你在嵌入式环境里用 C 语言实现无锁原语，或者手写内联汇编时，volatile 可以作为“阻止编译器优化掉内存访问”的补充手段。不过在 C++ 标准库的 Framework 下，请放心去掉 volatile。

真正需要 volatile 的场景是 memory-mapped IO，也就是访问硬件寄存器时，这跟线程同步完全是两码事。千万别把这两者搞混。

6.2 假共享（False Sharing）：隐蔽的性能杀手

假共享不是逻辑错误，而是性能灾难。CPU 缓存以 cache line 为粒度加载和同步，一个 cache line 通常是 64 字节。如果两个原子变量恰好落在同一个 cache line 上，而且被不同线程频繁更新，那么每次一个线程写自己的变量，都会导致另一个线程的整个 cache line 失效，即使它们访问的地址完全不同。

一个典型的案例是：

cpp复制struct alignas(64) SharedCounters {
    std::atomic<long> a;
    std::atomic<long> b;
};

如果不加 alignas(64)，a 和 b 大概率在同一个 cache line 里。线程 1 只更新 a，线程 2 只更新 b，理论上没有共享，但缓存一致性协议会让它们互相“打架”。加上 alignas(64) 后，a 和 b 被拆到不同的 cache line 里，性能可能立竿见影地提升数倍。

排查假共享的经验是：perf 里看 cache-misses 和 cache-line-bouncing 相关的事件（不同平台事件名不同），如果发现原子变量的 cache miss 率异常高，就要怀疑假共享。

6.3 无锁并不总是比锁快

这点值得反复强调。无锁代码在低竞争下通常比锁快，因为省去了系统调用和线程切换。但在高竞争下，CAS 循环会让大量线程空转重试，CPU 占用率飙升，吞吐可能反而不如一个写得很好的自旋锁或者读写锁。

另外一个很多人忽略的点是：普通互斥锁在低竞争时其实非常快，fast-path 下也就是用户态一次原子比较加分支预测，开销比无锁多不了多少。真正慢的是锁的 slow-path，即线程睡眠和唤醒。所以如果你的共享数据访问频率不是极端高，或者临界区本来就不小，无锁带来的收益会非常有限，而代码维护成本是实打实的。

我遇到过最尴尬的案例是：一个无锁队列改造后吞吐没有提升，反而因为 delete 节点时的内存回收处理，引入了偶发段错误，最后排查了整整两天。所以我的态度一直是：无锁是最后三公里的优化手段，不是工程起步的首选。

6.4 内存回收（Memory Reclamation）到底有多难

前面在无锁栈里已经提到过，pop 节点的删除是一个大坑。在无锁数据结构里，没有一把全局锁能保证“没有线程正在访问这个节点”，所以你没法安全地直接 free。

Hazard pointer 是其中一个可行方案。基本思路是：每个读线程预留一个 slot，在访问节点之前把要保护的指针写入 slot，并加上 release 屏障；删除线程回收节点前，检查所有 hazard pointer，如果没人在用才真正释放。实现存在明显的复杂度，slot 数量有限，而且读线程必须记得清理槽位。

Epoch-based reclamation（EBR）是另一个流派。它把时间分成若干个 epoch，每个线程操作时声明自己所在的 epoch。当一个 epoch 里的所有线程都离开后，之前在这个 epoch 里产生的待回收节点才真正可以释放。EBR 实现起来比 hazard pointer 简单，但存在一个隐患：某个线程长时间不离开当前 epoch，会导致回收被无限期推迟。

现实中还有一种更“怂”的做法：如果数据体不大、延迟可接受，就把 pop 出来的节点放进一个全局的待回收列表，由一个后台线程定期处理。这已经不是严格意义上的无锁，因为后台回收线程可能阻塞，但对很多业务场景够用了。

6.5 TSan 和压力测试：无锁代码的唯一救星

C++ 的内存模型语义非常精细，光靠人眼 review 无锁代码，很容易漏掉那些只在特定重排下才会触发的 Bug。所以我的工作流里一定会有两道守卫。

第一道是 ThreadSanitizer（TSan）。编译时加上 -fsanitize=thread，它能检测数据竞争、错误的内存序使用。不要以为无锁代码没有锁就不会有数据竞争，只要有一个普通变量的读写没有被原子操作或锁保护，TSan 都会第一时间抓出来。不过 TSan 需要编译器插桩，所以它检测的是“你的源码里是否存在未同步访问”，而不是运行时的指令重排，因此它找不出因内存序选弱到导致逻辑错误的 Bug。

第二道是压力测试。我会拿一个带有合法内存访问模式的工作负载，在多核心的 x86 和 ARM 机器上跑足够长的时间，同时对比“强内存序版本”和“弱内存序版本”的输出是否一致。这一步非常关键，因为很多内存序问题只会在特定调度时序下暴露，跑三五分钟是不够的，至少得挂机跑上一整晚。

6.6 无锁队列的常见替代方案

如果你需要的只是一个高效的多生产者多消费者队列，我的建议是优先看看现成实现。

boost::lockfree::queue 用起来很省心，内部已经处理了内存回收。moodycamel::ConcurrentQueue 是另一个我很常用的库，它针对高并发读写做了大量优化，代码质量很高，值得作为学习素材去读。

有时候你会发现，一个带条件变量的阻塞队列加上“无锁的计数器统计”，就能覆盖 90% 的业务需求。剩下那 10% 真正需要全无锁的场景，再考虑手写专用结构。我的原则一直是：能用锁解决就别无锁；一定要无锁，就先从标准库和成熟库中找轮子；轮子不合适，再重读一遍内存模型文档，最后才开始写。

6.7 热点问题速查表

7. 我最后想说的几句大实话

做了几年无锁编程，踩过很多次坑之后，我最大的体会是：无锁编程的门槛不在语法，而在思维模型。你写出来的每一行代码，都不是只在自己的线程里顺序执行，而是要在“可能被任意重排”的多核世界里建立秩序。C++11 把内存序摆在你面前，是给你一把精细控制并发语义的手术刀，而不是一个可以乱用的魔术棒。

我曾经为了炫技，把一段完全可以用 std::mutex 解决的代码硬写成无锁版本，结果花了三倍的时间调试，最后还因为一个 ABA 问题差点造成线上事故。从那以后我给自己定了一条规矩：无锁代码必须伴随注释，解释每个原子操作使用特定内存序的原因。这既是写给同伴看的，也是写给我自己看的——半年后再打开这段代码，我不可能记得当时的每一个重排推演。

如果你刚接触无锁编程，我的建议是从“单生产单消费”“高频计数器”“一次性指针发布”这类小场景入手，再用 std::atomic 把一个小模块从锁改成无锁，对比性能。不要一开始就挑战无锁队列和无锁哈希表，那里面光是内存回收就够你熬几个通宵。

最后分享一个排查无锁问题的小技巧：当你的无锁程序偶发出错又无法稳定复现时，先在 x86 上用默认 seq_cst 跑通，再在 ARM 环境或加入随机化的环境里反复跑。如果切换到弱内存序后问题出现频率明显升高，基本可以锁定是内存序配错了。反过来，如果任何内存序下都稳定复现，那大概率是 ABA 或内存回收的锅，跟重排关系不大。这个二分法能帮你少走很多弯路。