C++11内存序与无锁编程：从原子操作到无锁队列实践

1. 无锁编程：先搞清楚它到底在解决什么问题

做并发编程的这几年，我见过太多人一上来就抱着无锁编程的各种技巧猛啃，结果项目里堆了一堆 atomic<int>，性能没提上去，反而多了几个极其诡异的偶发崩溃。今天这篇文章，我想从一个干了多年并发开发的从业者视角，把无锁编程和原子操作这件事从头到尾捋一遍，包括我们最关心的那个问题：C++11 里那套内存序，到底是不是专门为原子操作准备的。

先说清楚一个概念。无锁编程，英文叫 lock-free programming，核心诉求是：当多个线程同时访问共享数据时，不借助操作系统提供的互斥锁（mutex）等同步原语，而是依靠硬件层的原子指令来保证数据的一致性。

为什么要绕开锁？因为锁有几个天生的痛点。第一是阻塞，线程拿不到锁就得挂起等待，线程切换是有开销的，这个开销在锁竞争激烈的时候会被无限放大；第二是死锁风险，锁的获取顺序一旦出了纰漏，整个进程直接卡死；第三是优先级反转，低优先级线程持锁不放，高优先级线程反而被拖住，这在实时系统里是致命的。

但这不代表无锁编程就是银弹。它真正的适用场景，是在锁竞争程度高、临界区非常短、或者对延迟有严苛要求的场景下。比如网络库里的连接池、高频交易系统的事件队列、游戏引擎里的任务调度器。相反，如果你只是偶尔让两个线程同步一下状态，mutex 十有八九是更好的选择——它简单、易证、不容易出错。无锁编程的正确姿势是：先用锁，性能瓶颈分析确认了锁的问题，再考虑无锁改造。

2. 原子操作：一切无锁编程的地基

无锁编程听起来玄妙，但落到最底层，全是原子操作在撑着。所谓原子操作，就是一个操作在执行过程中不可被中断，对其它线程表现为要么完全发生，要么完全不发生。在单核时代，一条普通的 i++ 可能本身就不会被打断的假象还凑合。但多核时代完全不是这么回事——一条 i++ 在汇编层面通常要经历"读取到寄存器、修改、写回内存"三步，两个线程同时执行时，互相覆盖写结果是家常便饭。

2.1 CPU 层面的原子指令：CAS 和 RMW

要保证"读-改-写"这个完整过程不被干扰，CPU 提供了两类关键能力：

• 原子读改写指令（RMW, Read-Modify-Write）：比如 fetch_add、test_and_set，它们保证对同一个内存地址的读改写过程是原子的。
• 比较并交换指令（CAS, Compare-And-Swap）：x86 上是 CMPXCHG，ARM 上是 LDREX/STREX 配对实现。CAS 做的事情是：把内存里的值和预期值比较，如果相等就写入新值并返回成功，否则什么都不做并返回失败。

在 x86 平台上，这些指令前面通常还会加 LOCK 前缀，作用是锁定总线或缓存行，防止其它核心在指令执行期间改动同一个地址。ARM 的情形略有不同，它使用 LDREX 加载并标记地址，STREX 条件写入时如果发现地址已被其它核修改则返回失败。这就是我们常说的 LL/SC（Load-Linked/Store-Conditional）机制。

用生活化的类比来理解 CAS：就好比你在手机上调了高铁票的座位，提交订单前系统会再确认一次当前选中座位是否还是原座位。如果没被别人抢走，提交成功；如果已经被抢走，系统让你重新选座。这个"再确认一次"的动作就是 CAS 的"比较"。

2.2 C++11 的原子类型接口

C++11 标准把平台相关的原子指令抽象成了统一的接口，放在 <atomic> 头文件里。std::atomic<T> 支持 load()、store()、exchange()、compare_exchange_weak()、compare_exchange_strong() 等操作。其中 compare_exchange 就是 CAS 的 C++ 封装。

这里有个新手特别容易踩的坑：compare_exchange_weak 和 compare_exchange_strong 的区别。weak 版本在某些平台上可能出现"假失败"（spurious failure），即内存值明明等于期望值却返回失败。它性能略好，适合放在循环里配合重试逻辑使用。strong 版本则保证不会假失败。所以当你看到别人的代码里 CAS 外面套了个 while 循环，一个关键原因就是用 weak 版本时必须自旋重试，哪怕期望值正确也可能需要再来一轮。

说到 CAS 循环，无锁数据结构的基础玩法基本就是它了：读取当前状态，基于它计算出新状态，用 CAS 把状态从"当前"更新到"新状态"，如果 CAS 失败说明期间被别的线程改了，重试。这种"乐观地假设没人抢，抢了我就重来"的策略，和数据库的乐观锁思想如出一辙。

3. C++11 内存序：专门为原子操作准备的规则手册吗

这可能是大家最关心的部分，也是并发编程里最容易被忽略的一层。先说结论：C++11 的内存序确实是为原子操作这个大的并发框架而设计的，它规定了原子操作以及周边普通内存访问之间的可见性顺序。 你可以把它当成一份给编译器、CPU 和程序员三方共同遵守的"可见性契约"。

3.1 没有内存序会怎样：编译器和 CPU 都在偷偷重排

很多写过多线程程序的人都遇到过这种诡异情况：明明线程 A 先给某个变量赋了值，线程 B 却一直看不到；或者看到了变量新值，却发现它之前相关联的其它变量还是旧值。原因在于，编译器和 CPU 为了优化性能，会在保证"单线程语义不变"的前提下重排指令顺序。多线程环境下，这种重排会破坏多个变量之间的因果关系。

举个例子：

cpp复制int ready = 0;
int data = 0;

// 线程 A
data = 42;       // 普通写
ready = 1;       // 普通写

// 线程 B
while (ready != 1);   // 空转
assert(data == 42);   // 可能失败！

如果 ready 和 data 都是普通变量，编译器可能把 ready = 1 重排到 data = 42 之前，CPU 也可能在乱序执行时先让 ready 的写入对外可见。于是线程 B 看到了 ready == 1，但读到的 data 还是 0。

要解决这个例子的问题，就得把 ready 声明成 std::atomic<int>，并设置合适的内存序。之前我在做一个跨线程的事件分发模块时，就遇到过因为漏掉内存序导致线上偶发读到半初始化状态的问题，排查了整整两天，最后发现是一个普通 bool 标志位在跨线程传递信号，编译器把它优化出了乱序，想想都后怕。

3.2 六种内存序：从松到严

C++11 在 <atomic> 里定义了六种内存序枚举：

这段话如果干读，很容易懵。我换个方式讲。release/acquire 其实是一对"信使"：

• 线程 A 做 store(value, memory_order_release)，相当于把之前所有普通写操作都"打包"好，标记一个完成点。
• 线程 B 做 load(value, memory_order_acquire)，如果它读到了 A 写入的值，相当于拿到了 A 在 release 之前全部打包的内容，这些内容对 B 立即可见。

这就像寄快递。release 是确认箱子封好并贴上"已发货"标签，acquire 是收件人拿到包裹后知道箱子里所有东西都到了。如果收件人还没收到包裹标签，那箱子里东西的状态就无法保证。

而 seq_cst 是其中最严格的一档，它保证所有线程观察到的原子操作顺序是完全一致的，不存在任何"我觉得你先，你觉得我先"的分歧。代价是编译器通常需要在关键位置插入内存屏障指令，在弱内存模型的 CPU 上开销不可忽视。

3.3 回到那个热搜问题：内存序是不是专门给原子操作准备的

这个问题要分两个层面来看。

第一，内存序这个机制是为原子操作提供语义约束的，没有原子操作，内存序没有发挥的舞台。原子操作解决的是"操作是否原子不可拆"的问题，内存序解决的是"原子操作的可见性顺序如何保证"的问题，二者配合才构成完整的并发原语。所以问"内存序是不是专门为原子操作准备的"，答案是肯定的——它是原子操作这套体系里定义"顺序语义"的规则手册。

第二，内存序的影响范围并不仅限于那个原子变量本身。release 写会确保此前所有普通内存写对 acquire 读者可见，acquire 读会让自己之后的所有普通读写不被重排到读之前。这意味着，你在写无锁代码时，原子变量周边的普通变量也必须遵守它的秩序约束。换句话说，内存序是给整个内存系统定规则的，只不过规则的锚点是原子操作。

另一个容易被误解的点是，很多人以为 C++11 的原子操作内存序是 C++ 发明的。其实不然，它只是把 CPU 硬件层面已有的内存模型抽象成了可移植的语言级定义。x86 是强内存模型，日常读写操作天然保持顺序（除了少数存储转发场景需要屏障）；ARM 和 POWER 是弱内存模型，普通读写在 CPU 眼里几乎可以随意重排，必须显式插入屏障指令才能约束可见性。这就是为什么同一份无锁代码在 x86 上跑得好好的，移植到 ARM 设备上就出幺蛾子的根本原因。

4. 实操：手写一个无锁队列要过几道坎

理论聊完了，不写点代码总感觉不过瘾。我挑一个实际工程中利用率最高的数据结构——无锁 FIFO 队列，带大家完整走一遍。这里我先用一个相对简单的场景开场：单生产者、单消费者（SPSC）的环形队列，这是最容易写对、性能也最炸裂的无锁方案。

4.1 场景一：SPSC 环形队列，最实用的无锁入门

SPSC 环形队列的核心思路是，生产者和消费者各自维护自己的读写指针，而且读写互不交叉：

cpp复制template <typename T, size_t N>
class SPSCRingQueue {
    static_assert((N & (N - 1)) == 0, "N must be power of 2");
    alignas(64) std::atomic<size_t> write_idx_{0};
    alignas(64) std::atomic<size_t> read_idx_{0};
    T buffer_[N];

public:
    bool push(const T& item) {
        size_t w = write_idx_.load(std::memory_order_relaxed);
        size_t r = read_idx_.load(std::memory_order_acquire);
        if (w - r >= N) {
            return false;  // 队列已满
        }
        buffer_[w & (N - 1)] = item;
        write_idx_.store(w + 1, std::memory_order_release);
        return true;
    }

    bool pop(T& item) {
        size_t r = read_idx_.load(std::memory_order_relaxed);
        size_t w = write_idx_.load(std::memory_order_acquire);
        if (r == w) {
            return false;  // 队列已空
        }
        item = buffer_[r & (N - 1)];
        read_idx_.store(r + 1, std::memory_order_release);
        return true;
    }
};

这段代码有几个细节值得说。

第一，为什么生产者读 read_idx_ 用 acquire？因为生产者需要确保能看到消费者"已读走数据"的完整结果，也就是消费者 release 之前对缓冲区内容的读写都对生产者可见。同理，消费者读 write_idx_ 用 acquire，是为了看到生产者已经写入缓冲区的内容。这里如果图省事全用 relaxed，在 ARM 上数据竞争会立刻现出原形。

第二，alignas(64) 是干嘛用的？这是为了把两个频繁写入的原子变量放到不同的缓存行上，避免"伪共享"（false sharing）。什么叫伪共享？两个线程各自改不同的变量，但这俩变量碰巧落在同一条缓存行里，CPU 缓存一致性协议会让这行数据在多个核心之间反复失效、重新同步，性能损失比加锁还严重。我实测过，一个高频热点的双变量结构，加上 alignas 隔离缓存行后，吞吐能提升好几倍。

第三，环形索引用 N & (N - 1) 取模，前提是 N 为 2 的幂。这种位运算是环形缓冲区的常规优化，在高频场景下少一次除法指令，积少成多。

SPSC 队列的最大优势是：不需要 CAS，两个线程各自写各自的索引，天然不会冲突。所以它不是严格意义的"多生产者多消费者无锁队列"，但它是理解无锁队列的完美起点。游戏引擎的指令提交、音频处理线程和主线程之间的数据交换，用这套方案已经绰绰有余。

4.2 场景二：MPSC 用 CAS 实现无锁栈

再进阶一点，看一个多生产者场景。无锁栈（Lock-Free Stack）是教学里最经典的 CAS 例子，它以链表为存储结构，每个节点包含数据和 next 指针。所有生产者竞争同一个 head 指针，push 操作伪代码如下：

cpp复制void push(int value) {
    Node* new_node = new Node(value);
    Node* old_head = head_.load(std::memory_order_relaxed);
    do {
        new_node->next = old_head;
    } while (!head_.compare_exchange_weak(
        old_head, new_node,
        std::memory_order_release,
        std::memory_order_relaxed));
}

这里的关键是 compare_exchange_weak 的第一个参数 old_head 是引用传递。CAS 失败时，它会自动把 old_head 更新为当前最新的 head 值，这样循环重试时无需重新 load。这是 CAS 循环里最常见的优化写法。

但是——问题来了。无锁栈看似简单，一旦加入 pop 操作，ABA 问题就浮出水面。ABA 问题指的是：线程 A 读到了 head 指向节点 X，然后挂起；期间线程 B push 又 pop 节点 X，并 push 了节点 Y；等线程 A 恢复时，它 CAS 的比较对象仍然是节点 X 的地址，而此刻 head 确实又指向了 X 这个地址。于是 CAS 成功，但实际的链表结构已经变了，A 的更新建立在过期数据之上，程序直接崩溃或者产生逻辑错误。

ABA 问题在无锁数据结构里几乎避无可避，常见的对策有：

• 带标签的指针（tagged pointer）：把指针的低位或高位绑定一个递增版本号，每次修改都让版本号加一，CAS 时同时比较"地址+版本号"。这样即使地址复用，版本号对不上，CAS 依然失败。
• 延迟回收内存：不让被 pop 的节点立刻释放，而是放进一个专门的"待回收列表"，等确认没有线程还在引用它之后再真正 free。这就是 hazard pointer 和 epoch-based reclamation 的由来。

我自己的经验是，无锁数据结构的难点从来不在"入队出队"本身，而在内存回收和 ABA 治理。如果你只是写个学习性质的 demo，跳过这块没问题；但上生产环境的话，内存管理方案必须先于数据结构设计确定下来，否则后面补困难重重。

4.3 从无锁栈到无锁队列：Michael-Scott 队列的简要思路

要支持多生产者多消费者（MPMC）的无锁队列，业界最经典的方案是 Michael-Scott 队列。它的思想是：维护一个带 dummy 节点的链表，head 永远指向 dummy，tail 指向队尾；入队时在 tail 后插入新节点并用 CAS 更新 tail，出队时用 CAS 把 head 从 dummy 后移到下一个节点。它同样面临 ABA、节点回收、tail 落后于 head 等棘手问题。实现完整可用的 MPMC 队列代码量不小，过去十年社区也催生了像 boost::lockfree::queue、moodycamel::ConcurrentQueue 这样成熟的库。

所以我的建议是：能别自己造轮子就别造轮子。 除非你真的需要极致定制，或者有浓厚的兴趣把它彻底搞懂，否则直接用经过大规模检验的第三方库更稳妥。你花两天手写的 MPMC 队列，大概率没有 moodycamel 在十几种平台上打磨过的实现性能好、Bug 少。

5. 常见问题与排查技巧实录

无锁编程写起来一时爽，排查起来火葬场。这个说法一点不夸张。因为它出问题的场景往往不可复现、只在特定 CPU 模型下触发、而且经常是"数据明明是对的，逻辑却莫名其妙不对"。我把这几年踩过的坑整理成一份清单，能帮你省下大把 debugging 时间。

5.1 症状一：代码在 x86 上一切正常，ARM 上随机崩溃

原因基本都是弱内存模型下可见性没有保障。x86 的强内存模型掩盖了大量顺序问题，你的 relaxed 语义在 x86 上碰巧表现正常，一到 ARM 就被乱序彻底打脸。排查方法是审查每一对"发布-消费"关系，确认内存序配对正确：写侧用 release，读侧用 acquire，或者干脆先全上 seq_cst 把正确性问题清零，再逐步放宽。

5.2 症状二：偶发读到"半更新"的对象

这种问题通常是你把普通变量和原子变量混着用，且依赖了原子变量周围普通变量的可见性，却没给它们安排内存序。从设计上就要警惕：凡是跨线程共享的、彼此有因果关系的变量，要么统统纳入同一个锁或无锁结构体的保护，要么保证它们的读写被 release/acquire 对包住。 单独拎一个原子标志位出来想当然地做同步，是最容易埋雷的写法。

5.3 症状三：性能提升不明显，甚至更慢

无锁不等于高性能。无锁数据结构在高竞争下其实是靠 CAS 无限自旋在硬撑，CAS 失败重试本身就是开销。如果临界区里要做的事情比较多，或者原子操作频繁触发缓存行同步，无锁可能比 mutex 还慢。另一个性能杀手就是我前面提到的伪共享。排查时可以用 perf 等工具观察 cache miss 率，如果发现大量缓存行冲突，优先检查共享数据结构的内存布局。

5.4 症状四：调试器下复现不了，release 版必现

这是典型的编译器重排或优化问题。解决问题的一个有效工具是 -fsanitize=thread（ThreadSanitizer，简称 TSan），它能在运行时检测数据竞争，并指出涉及的代码行。我在写无锁代码时会在测试编译选项里常开 TSan，虽然在低层无锁结构上它可能有误报，但对发现可见性问题极其有效。另外一个笨但可靠的办法是 code review 时逐对检查内存序配对，把 release/acquire、relaxed 的用途在注释里写清楚，让后来人（包括三个月后的自己）能看懂。

这里再分享一个排查技巧：一旦怀疑无锁代码出问题，先把代码里的内存序全部改成默认的 seq_cst 跑一遍。如果问题消失，说明就是内存序放得太松；如果问题还在，说明问题更多出在 ABA 或内存回收逻辑上。这个二分定位法比一开始就对着代码乱猜效率高得多。

6. 给打算上手无锁编程的人几句实在话

做完这么多项目，回头再看"无锁编程与原子操作"这件事，我的体会其实很朴素。

第一句，默认用锁，被逼才无锁。 mutex 经过了数十年验证，正确性容易推理，性能在绝大多数场景下也足够。只有在明确测量出锁是瓶颈，或者系统对延迟有极致要求时，才值得引入无锁方案。拒绝锁的人，往往是没吃过无锁的苦。

第二句，从最简模型开始。 SPSC 环形队列能解决的事，不要一开始就上 MPMC 队列。先看清楚你的生产消费模型到底是什么。多生产者多消费者听着厉害，但每提升一个维度，复杂度和出错概率都指数级上升。

第三句，内存序不是玄学，是你和硬件签订的契约。 把它当成规则手册仔细读，不要把 CPU 的"碰巧不乱序"当成程序语义。写代码时把内存序的意图写成注释，能避免无数后续的排查时间。

最后分享一个我最近项目里用到的小技巧：在做无锁容器的接口设计时，我习惯把内存序参数显式暴露出来，并给默认值，同时提供一套"安全模式"的编译开关，一键把全部内存序切回 seq_cst。这样开发期用安全模式保证正确性，压测期再切换成优化模式对比数据。实测下来，这个开关帮我挡下了至少两回准备上线的崩溃事故。你要是刚开始做无锁改造，不妨也试试这个路子。