去年我接手过一个网关服务压测到 8 个线程时吞吐上不去了CPU 占用已经拉满但网卡流量纹丝不动。火焰图一看一半以上时间都花在pthread_mutex_lock和pthread_mutex_unlock上锁内部的自旋、系统调用、上下文切换把整个服务拖死。也就是从那时候起我开始系统研究无锁编程与原子操作把核心链路里的互斥锁一个个替换成无锁队列和无锁计数器才把性能瓶颈捅破。这篇文章不讲虚的只讲我在实际项目里怎么理解无锁编程、怎么用原子操作、怎么写一个能跑的无锁队列以及那些文档里不会告诉你的坑。适合已经写过多线程代码、被锁坑过、想往高性能方向走的同学。如果你完全没接触过并发编程建议先把std::mutex用熟再来读这篇否则有些概念会比较吃力。1. 锁慢并非错觉从缓存一致性到上下文切换很多人以为锁慢是慢在“拿不到锁的时候要等待”其实这只是表象。锁真正的开销比大多数人想象的要复杂得多。1.1 锁争夺时线程的状态迁移当一个线程执行lock()时如果锁恰好空闲那么它需要执行一次原子性的 test-and-set 操作把锁状态从 0 改成 1。这个操作本身不算太贵但在 x86 上通常对应一次带lock前缀的指令会锁住缓存行甚至总线让其他核心的缓存失效。如果锁已经被别的线程持有当前线程就会陷入内核态进入休眠操作系统稍后要把它重新唤醒。这一睡一醒涉及线程状态切换、调度器运行、内核栈切换、缓存冷启动一次完整的上下文切换成本在微秒级别。当一个服务里大量线程争抢同一把锁时整个系统就像高峰期所有人挤一扇门真正做业务的时间很短大量时间都耗在排队、让路、再排队上。很多高并发系统里锁的争抢率其实并不高但每次抢锁都会产生缓存一致性流量。多个核心轮流修改同一个锁变量所有持有该缓存行的核心都要不断同步最新值这种“缓存行乒乓”甚至比锁本身更致命。1.2 伪共享一个你早晚要踩的坑伪共享false sharing是锁之外最容易忽略的性能杀手。它指的是两个线程修改的是不同的变量偏偏这两个变量落在同一条缓存行通常 64 字节里。CPU 为了保证一致性会让这两个核心互相通知“这条缓存行被我改了”于是每个线程改自己的变量时对方的缓存行也会失效。看一个典型例子struct Counter { long long a; long long b; }; Counter c; // 线程1 一直修改 c.a // 线程2 一直修改 c.ba和b相邻极大概率落在同一条缓存行。两个线程即使完全没有共享变量也会因为缓存行同步而互相拖慢。解决办法是在变量之间补齐缓存行struct alignas(64) CounterA { long long value; }; struct alignas(64) CounterB { long long value; };我在写无锁队列时生产者的写索引和消费者的读索引必须分散到不同的缓存行原因就在这里。如果不做隔离无锁队列可能比加锁队列还要慢而且慢得莫名其妙。2. 原子操作与内存序无锁编程的地基无锁编程的核心不是“不用锁”而是“用原子操作替代锁”。要理解原子操作先得搞清楚它和普通变量的本质区别。2.1std::atomic与内建变量的本质区别普通变量的读写不是原子的。两个线程同时对同一个int做最终结果可能比预期小因为在机器层面是“读取-修改-写回”三步。使用std::atomicint后fetch_add(1)保证这个三步操作作为一个整体完成不会被其他线程穿插。但这只是最基础的部分。原子操作还解决了一个更隐蔽的问题内存可见性。即使一个线程对普通变量写入后另一个线程紧接着读取也不能保证读到最新值。CPU 和编译器为了性能可能会重排指令或者让写操作停留在寄存器/写缓冲区中直到某个时机才刷出内存。std::atomic把这种不确定性锁住了。C 标准规定一个变量如果至少一个线程在写其他线程在读且两者不同步那就产生数据竞争未定义行为。而原子变量配合合适的内存序能建立“ happens-before 关系”让跨线程的数据传递变得有章可循。2.2 内存序不是玄学relaxed、acquire、release 到底怎么用std::atomic的每个操作都可以指定memory_order常见的有四种memory_order_relaxed只保证操作本身原子不提供任何跨线程的先后顺序保证。适合计数器、统计量这类本来就不依赖顺序的场景。memory_order_release写操作使用。它保证“本次写入之前的所有普通读写都不能被重排到这次写入之后”。memory_order_acquire读操作使用。它保证“本次读取之后的所有普通读写都不能被重排到这次读取之前”。memory_order_seq_cst默认选项。它比 acquire/release 更强的点在于还保证所有线程看到的操作顺序是一致的代价也最高。release 和 acquire 通常成对出现。一个经典场景是“发布数据”std::atomicbool ready; std::string message; // 生产者 message hello; ready.store(true, std::memory_order_release); // 消费者 while (!ready.load(std::memory_order_acquire)) {} std::cout message std::endl;release 操作像是一道栅栏把前面的message hello牢牢挡在 store 之前。消费者 acquire 读到ready true后能确定message一定已经写好了。这就是我在无锁队列里传递数据的底层逻辑。很多人一上来就用默认的seq_cst这当然不会错但在弱内存序的 CPUARM、PowerPC上性能差异明显。我个人的习惯是先把功能跑通再逐个把内存序降到最低限度同时用压力测试验证正确性。2.3 C 语言硬核玩家stdatomic.h的使用C 语言同样提供原子操作。C11 标准引入了stdatomic.h用法和 C 类似但不完全一样。#include stdatomic.h atomic_int counter 0; void add_one(void) { atomic_fetch_add_explicit(counter, 1, memory_order_relaxed); }C 的原子类型就是普通类型的别名包装访问时必须通过atomic_load、atomic_store这些函数不能像普通变量那样直接赋值。C 里可以直接写counter.store(x)C 里不太建议直接对atomic_int变量赋值因为语义不明确容易踩坑。如果你在做 C 语言的服务端程序却又想享受无锁队列的好处stdatomic.h是唯一标准路径。Linux 内核里大量使用atomic_long_t和smp_store_release之类的东西本质上也是同一套思路。3. 实战手写一个无锁 SPSC 队列SPSC 是 Single Producer Single Consumer 的缩写指单生产者单消费者。这是无锁编程里最容易入门、也最实用的结构。音频处理、日志采集、游戏引擎的事件传递到处都有它的身影。3.1 为什么先从 SPSC 入手多生产者多消费者MPMC之所以难是因为多个线程同时修改同一个索引必须有 CAS 参与还要处理 CAS 失败后的重试以及复杂的内存回收。而 SPSC 场景下生产者只改自己的写索引消费者只改自己的读索引两者只通过索引差值判断队列是否满/空天然不需要锁。SPSC 的核心是环形缓冲区也叫 ring buffer。数组长度取 2 的幂这样就可以用位运算代替取模。我写了一个最小实现#include atomic #include vector #include cstddef template typename T class SpscRing { public: explicit SpscRing(size_t powerOfTwo) : capacity_(powerOfTwo), mask_(powerOfTwo - 1), buffer_(powerOfTwo) {} bool Push(const T value) { const size_t h head_.load(std::memory_order_relaxed); const size_t t tail_.load(std::memory_order_acquire); if (h - t capacity_) { return false; // 队列已满 } buffer_[h mask_] value; // 普通写 head_.store(h 1, std::memory_order_release); return true; } bool Pop(T value) { const size_t t tail_.load(std::memory_order_relaxed); const size_t h head_.load(std::memory_order_acquire); if (t h) { return false; // 队列已空 } value buffer_[t mask_]; // 普通读 tail_.store(t 1, std::memory_order_release); return true; } private: size_t capacity_; size_t mask_; std::vectorT buffer_; std::atomicsize_t head_{0}; std::atomicsize_t tail_{0}; };代码里的关键点Push里先读tail判断队列是否还有空位。注意tail_用的是 acquire 而不是 relaxed因为必须确保消费者之前读过的槽位已经完成释放生产者才能安全覆写。Pop里先读head用 acquire 确保能看到生产者最新的 release 写入之后再读数组元素才安全。数据数组元素本身是普通变量不需要原子。因为它通过head_的 release/acquire 形成了 happens-before 关系。这个队列的容量是 2 的幂所以h mask_能正确回绕。索引用size_t无符号整数方便做差值判断。当h和t都回绕时只要差值在容量范围内判断依然正确。3.2 缓存行隔离和条件编译细节我的第一版 SPSC 队列在生产环境表现很差排查半天发现head_和tail_两个原子变量挨在一起正好落在同一条缓存行。生产者和消费者各自修改不同的变量却互相拖累。修复方式是给它们单独对齐struct alignas(64) Head { std::atomicsize_t value{0}; }; struct alignas(64) Tail { std::atomicsize_t value{0}; };然后把队列里的head_、tail_换成Head head_;和Tail tail_;访问时写成head_.value.load(...)。这样两个原子变量至少在 64 字节之外缓存行乒乓问题彻底消失。这里还有个容易忽略的点队列容量是 2 的幂不代表capacity_可以随便传。我在构造函数里加了断言assert((powerOfTwo (powerOfTwo - 1)) 0); assert(powerOfTwo 0);否则mask_计算会出错整个队列的数据位置全乱。3.3 内存序检查别急着全部 relaxed功能跑通后我试着把Push里的tail_.load改成 relaxed、把Pop里的head_.load改成 relaxed想省一点开销。实测在 x86 上性能几乎没变化但这在 ARM 上可能就会出问题。因为 x86 的硬件内存模型本身偏强很多弱内存序需要的屏障在 x86 上天然不存在而 ARM 是典型弱内存序release/acquire 会生成真正的内存屏障指令。我的建议是在 x86 上开发调试时按“能看懂的顺序”写好 release/acquire不要图快用 relaxed。等代码验证正确了再用压测对比降低内存序前后的差距。对大多数业务场景这个差距可以忽略但正确性上的风险却很大。4. 脏活才是难点内存回收与 ABA 问题数组型无锁队列解决了内存回收问题因为数据槽是预分配的。但如果你要实现无锁栈、无锁链表、MPMC 队列就必须面对两个绕不开的难题ABA 问题和动态节点的回收。4.1 ABA 问题到底是怎么发生的ABA 问题最经典的场景在无锁栈上。考虑一个top指针初始指向节点 A。线程 1 读出top A然后准备 CAS 把top改成A-next。在线程 1 还没执行 CAS 之前线程 2 先弹出 A再把 B、C 压栈最后又压入一个 A可能是重新分配的内存地址恰好和原来的 A 相同。线程 1 的 CAS 比较时发现top还是 A于是 CAS 成功但它实际把top指向的是新的 A 的 next而这个 next 早被线程 2 改过了栈结构立刻损坏。教科书上经常说“ABA 的本质是内存地址被复用。”但只要节点是动态分配和释放的地址复用就不可避免。很多无锁队列之所以一跑多线程就崩根因都在这里。解决办法有很多最简单的是给每个指针带一个版本号让 CAS 同时比较地址和版本号。在 C 里可以这样struct alignas(16) TaggedPtr { void* ptr; uint64_t tag; }; std::atomicTaggedPtr top;CAS 时同时比较ptr和tag每次成功更新就tagABA 就很难发生。但要小心两个成员必须保证能在一个原子对象里比较所以结构体的对齐和大小要特别注意。4.2 无锁结构的内存回收三件套就算解决了 ABA动态节点被一个线程释放、另一个线程还在读仍然会崩溃。无锁编程里回收内存的常用手段有三种Hazard Pointer风险指针每个线程维护一个全局可见的指针数组读取节点前先把自己的指针注册到数组里表示“我正在读这个节点谁也别释放它”。完成操作后再注销。这个方案实现简单但每次读写都要检查所有线程的风险指针缓存开销不小。Epoch Reclamation基于世代的回收全局维护一个世代计数线程进入临界区时递增计数退出时判断是否所有线程都离开了旧世代。如果是就可以安全释放旧节点。这个机制实现复杂但性能比 hazard pointer 好。Free List无锁空闲链表释放的节点不真正归还系统而是塞进一个无锁空闲链表后续新节点从空闲链表取。这样避免了内存地址立即被系统回收配合版本号可以进一步降低 ABA。我在实际项目里更偏好“不产生动态节点”的设计。能用数组预分配的就用数组能复用对象池就复用对象池。无锁编程的其他复杂度都可以通过设计绕开唯独内存回收绕不开它也占了整个调试成本的大头。5. 基准测试与优化别让无锁变成负优化写无锁代码最怕的是自我感动——明明用了几重 acquire/release压测结果却比互斥锁还差。这种情况太常见了因为我上面说过锁在低竞争下并不慢而无锁结构如果没有控制好缓存行和内存序性能反而会崩。5.1 正确的压测姿势我的基准测试通常分三步固定线程数固定请求量统计总耗时。把线程数从 1 逐步增加到 16观察吞吐曲线。记录尾延迟P99、P99.9而不只是平均值。平均值很容易骗人。我在一个 SPSC 队列的压测里平均延迟看起来只有 100 纳秒直到画出直方图才发现有 0.1% 的请求延迟超过 10 微秒原因是生产者偶发地撞上消费者正在更新tail_。虽然无锁避免了上下文切换但缓存一致性流量仍然可能造成毛刺。互斥锁在低竞争时的平均性能往往和无锁结构差不多但高竞争下会迅速恶化。无锁结构理论上能保持平稳但只在你把缓存行隔离、内存序选择、CAS 重试策略都做对的前提之下。我习惯在压测时先关掉动态调频绑核运行然后交替对比互斥锁队列我的 SPSC 无锁队列我的 SPSC 无锁队列但去掉缓存行对齐看看对齐带来的收益表格是我常用的一种总结方式方案线程数吞吐量尾延迟std::mutex队列1 读 1 写1.0x1.0xSPSC 无锁队列1 读 1 写3.2x0.7xSPSC 无锁队列未对齐缓存行1 读 1 写1.8x1.3x差距非常直观。5.2 什么时候不要用无锁无锁编程不是银弹。我在以下场景里会坚定地继续使用锁并发度很低锁基本不争抢。此时锁的开销完全可以忽略无锁代码却增加了理解成本和维护成本。临界区本来就做了很多重操作比如磁盘 IO、网络请求。锁的等待时间占比很小优化锁没有意义。数据结构非常复杂比如需要支持随机删除的并发跳表。无锁实现难度极高正确性极难验证收益却可能被复杂度吃掉。无锁的价值在于“让锁不再是瓶颈”而不是“消灭所有锁”。一个系统里最需要无锁的往往是核心链路上最频繁操作的那个小结构比如消息队列、共享计数器、状态标志位。其他地方的锁很多时候是可以保留的。5.3 调优时的几个实用检查点优化无锁代码时我会按这个顺序排查缓存行隔离是否做好生产者和消费者的共享变量是否分散内存序是否过强默认的seq_cst在弱内存序机器上会生成额外屏障能降就降。CAS 失败后的重试是否太频繁失败的 CAS 本身就是一种争抢信号连续失败说明并发度已经太高可能需要换数据结构。是否有动态节点分配malloc/free 和原子操作用在一起很可能把无锁的优势吃掉。最后分享一个我踩过的坑第一次调无锁队列时我自信满满地把所有操作都设成relaxed因为我觉得这个队列逻辑简单不会出问题。结果在多核 ARM 设备上跑了几分钟就复现数据错乱调了一整天最后发现是消费者读数组元素的顺序没有被保证。后来我把代码改成上面那种 release/acquire 严格配对的结构再用-fsanitizethread跑了一晚上才彻底稳定。从那以后我的原则就变成了先求正确再求性能先写最保守的内存序再逐步放宽永远不要相信“这个 CPU 上没问题”就等于“所有 CPU 上没问题”。如果你手头有现成的高性能队列实现比如 DPDK 的 rte_ring、LMAX 的 Disruptor 设计文档建议反复读源码。无锁编程这条路自己埋头造轮子不如先抄好轮子抄熟了再改造出适合自己业务的版本。