CLH自旋锁深度解析：从缓存行颠簸到高并发性能优化

CLH自旋锁深度解析：从缓存行颠簸到高并发性能优化

发布时间：2026/10/9 21:49:28
CLH自旋锁深度解析：从缓存行颠簸到高并发性能优化 1. 从一次线上抖动说起为什么需要理解CLH自旋锁前阵子帮一个做高并发交易系统的朋友排查问题现象很典型压测QPS刚到八千CPU利用率就飙到百分之九十以上但真正干活的线程没几个大部分时间都耗在了锁的争抢上。用性能分析工具一抓热点函数全落在某个同步原语上。当时我第一反应就是——这大概率是自旋锁的缓存行颠簸问题。后来把锁换成CLH队列锁同样的硬件配置QPS直接翻了一倍多CPU反而降下来了。这件事让我意识到很多人对自旋锁的理解还停留在“循环等待”这个层面知道它比互斥量轻量适合短临界区但真到了要选型、要调优的时候就说不清楚为什么有的自旋锁在几十个线程下就开始崩有的却能撑到几百个线程还稳如老狗。CLH自旋锁就是后者里的典型代表它的全称是Craig, Landin, and Hagersten Lock由三位研究者在上世纪九十年代初提出核心思想是用一个隐式的链表队列来组织等待线程每个线程只在自己的前驱节点上自旋从而把争抢范围从“全局共享变量”缩小到“本地缓存行”。这篇文章我会把CLH自旋锁从设计动机、数据结构、核心操作、内存序语义、到实际编码实现和调优经验完整地拆一遍。适合已经了解基本锁概念、想深入理解高性能同步原语的开发者也适合正在做并发框架选型、需要判断什么时候该用CLH什么时候不该用的工程师。读完之后你应该能自己手写一个可用的CLH锁并且知道它在什么场景下会退化、怎么规避。2. CLH自旋锁的整体设计思路拆解2.1 传统自旋锁的痛点缓存行颠簸要理解CLH为什么这么设计得先看清楚它要解决什么问题。最朴素的自旋锁就是一个原子变量比如用atomic_flag或者atomicint所有线程都在这个变量上做CAS或者test-and-set。问题在于这个变量是所有线程共享的在缓存一致性协议下它会在不同核心的缓存之间来回弹跳。我举个具体的场景假设有十六个核心每个核心上跑一个线程都在抢同一把锁。当锁被核心零持有的时候其他十五个核心的缓存里这个变量都是失效状态。核心零释放锁时会修改这个变量导致其他十五个核心的缓存行全部失效。然后这十五个核心同时发起读取缓存一致性协议要处理十五个并发请求总线流量瞬间爆炸。更糟的是只有一个核心能抢到锁其他十四个核心白跑一趟继续下一轮争抢。这就是所谓的缓存行颠簸线程越多颠簸越严重扩展性极差。2.2 CLH的核心洞察把争抢分散到各个节点CLH锁的设计者想明白了一件事既然所有线程盯着同一个变量会颠簸那能不能让每个线程盯着一个不同的变量答案就是队列。每个等待线程在自己的前驱节点的一个字段上自旋而不是在全局变量上自旋。前驱节点的这个字段只会被前驱线程修改一次也就是它释放锁的时候。所以每个线程的自旋实际上是在等一个“本地”的、只属于自己的缓存行发生变化。这个设计带来的直接好处是当锁被释放时只有直接后继那一个线程的缓存行会失效其他线程的缓存行不受影响。缓存一致性协议的流量从O(n)降到了O(1)。这就是CLH锁扩展性好的根本原因。2.3 隐式队列与显式队列的取舍CLH锁的队列是隐式的每个线程只需要持有自己的节点以及一个指向前驱的指针。线程通过前驱指针串成一条链不需要一个全局的队列头尾指针来维护。这和另一种著名的队列锁MCS锁正好相反MCS锁是显式队列每个线程在自己的节点上自旋前驱释放时修改后继的节点。两者各有优劣后面我会专门做对比。隐式队列的好处是入队和出队操作更简单不需要原子地更新全局尾指针。但代价是它不太容易实现超时和取消因为一个线程无法直接知道自己的后继是谁。这个特性决定了CLH更适合那些线程不会中途退出的场景比如线程池里的工作线程。2.4 为什么选择自旋而不是阻塞有人可能会问既然都排队了为什么不直接阻塞等待让出CPU这就涉及到自旋锁的适用场景了。CLH锁的设计假设是临界区非常短通常只有几十到几百个时钟周期。在这种情况下线程阻塞和唤醒的开销包括系统调用、上下文切换、调度器介入加起来可能要几千个时钟周期远大于自旋等待的时间。所以自旋是更优的选择。但如果临界区很长自旋就会浪费大量CPU。这时候应该用阻塞锁或者用自适应策略先自旋一段时间再阻塞。CLH锁本身是纯自旋的实际工程中往往会结合自适应策略使用。3. 核心数据结构与内存布局解析3.1 节点结构的设计细节CLH锁的节点结构看起来很简单但每个字段的设计都有讲究。一个典型的节点包含两个核心字段一个表示锁状态的布尔值或者枚举另一个是指向前驱节点的指针。struct CLHNode { std::atomicbool locked; CLHNode* prev; };locked字段是前驱线程用来通知后继线程“我已经释放锁了”的标志。初始状态下每个新节点的locked都是true表示锁被占用。当前驱线程释放锁时它把自己的locked设为false后继线程看到这个变化就知道可以进入临界区了。prev指针指向前驱节点这个指针在入队时设置之后不再改变。注意这个指针不需要是原子的因为它只被当前线程读写其他线程不会碰它。3.2 为什么locked要用原子类型locked字段必须用原子类型因为它会被两个线程访问前驱线程写后继线程读。这里存在数据竞争必须用原子操作来保证可见性和顺序性。但注意这里不需要CAS只需要load和store。后继线程用acquire语义的load来读前驱线程用release语义的store来写。这样就能保证前驱线程在释放锁之前的所有内存操作对后继线程获取锁之后都是可见的。这个内存序的配对是CLH锁正确性的关键很多人手写的时候容易在这里出错用默认的seq_cst虽然正确但性能有损失用relaxed则完全错误。3.3 伪共享问题与缓存行对齐节点结构还有一个容易被忽略的问题伪共享。如果两个节点的locked字段落在同一个缓存行里那么一个线程修改自己的locked会导致另一个线程的缓存行失效又回到了颠簸的老路。所以高性能实现里节点通常要做缓存行对齐确保每个节点的locked字段独占一个缓存行。struct alignas(64) CLHNode { std::atomicbool locked; CLHNode* prev; // 填充到64字节 char padding[64 - sizeof(std::atomicbool) - sizeof(CLHNode*)]; };64字节是常见CPU的缓存行大小但不同架构可能不同实际工程中会用std::hardware_destructive_interference_size来获取。这个对齐会浪费一些内存但换来的性能提升在竞争激烈时非常显著。3.4 队列的隐式维护方式CLH锁的队列维护靠的是每个线程的本地变量myNode和一个共享的tail指针。入队时线程把自己的节点地址原子地交换到tail拿到的旧值就是自己的前驱。这个操作是整个CLH锁里唯一的原子RMW操作也是竞争最激烈的地方。CLHNode* prev tail.exchange(myNode, std::memory_order_acq_rel); myNode-prev prev;注意这里用的是exchange而不是CAS循环因为exchange是无锁的不需要重试。这也是CLH锁比某些基于CAS的锁更高效的原因之一。4. 加锁与解锁的完整流程拆解4.1 加锁操作的逐步分析加锁操作可以拆成三步。第一步是初始化自己的节点把locked设为true。第二步是用exchange把自己挂到队尾同时拿到前驱节点。第三步是在前驱节点的locked上自旋直到它变成false。void lock() { myNode-locked.store(true, std::memory_order_relaxed); CLHNode* prev tail.exchange(myNode, std::memory_order_acq_rel); myNode-prev prev; while (prev-locked.load(std::memory_order_acquire)) { // 自旋可以加pause指令 } }这里有几个细节值得说。myNode-locked的store用relaxed就够了因为这个值只被自己读不会被其他线程读。exchange用acq_rel因为它既要保证之前的操作不被重排到后面也要保证之后的操作能看到前驱的释放。自旋的load用acquire和释放时的release配对。4.2 解锁操作的微妙之处解锁操作看起来更简单就是把当前节点的locked设为false。但这里有个容易踩的坑解锁之后当前节点不能被复用因为后继线程可能还在读它的locked字段。如果当前线程马上又去加锁复用了同一个节点就会导致后继线程读到错误的状态。void unlock() { myNode-locked.store(false, std::memory_order_release); // 注意myNode不能立即复用 }正确的做法是每次加锁都用一个新节点或者用一个节点池但节点回收要等后继线程确认已经通过。这也是CLH锁实现里比较麻烦的地方后面讲实现时会详细说。4.3 内存序的配对关系CLH锁的正确性依赖于三对内存序的配对。第一对是解锁时的release store和加锁自旋时的acquire load这对保证了临界区的内存操作不会泄漏到锁外面。第二对是exchange的acq_rel它保证了入队操作和前驱的释放之间的顺序。第三对是节点初始化的relaxed store和自旋的acquire load虽然这对不是严格必须的但加上更保险。很多人写CLH锁时喜欢全部用seq_cst简单不容易错但在x86上seq_cst的store需要加mfence指令性能损失不小。在ARM上损失更大。所以理解内存序的配对是写出高性能CLH锁的前提。4.4 自旋等待的优化技巧自旋等待本身也有优化空间。最简单的就是空循环但这样会让CPU满负荷运转功耗高而且可能影响同核心上其他超线程的性能。更好的做法是在循环里加pause指令x86上是_mm_pause()ARM上是yield指令。pause指令有两个作用一是减少自旋带来的功耗二是给超线程的另一个逻辑核心让出执行资源。再进一步可以在自旋若干次之后调用sched_yield()让出CPU或者干脆阻塞。这就是自适应自旋锁的思路。不过对于CLH锁来说由于每个线程只在自己的前驱上自旋自旋时间通常很短加pause就够了不需要太复杂的自适应策略。5. 从零实现一个可用的CLH自旋锁5.1 基础版本的代码实现先给一个最基础但正确的实现方便理解核心逻辑。#include atomic #include thread class CLHLock { public: CLHLock() { tail.store(dummy, std::memory_order_relaxed); dummy.locked.store(false, std::memory_order_relaxed); } void lock() { CLHNode* node new CLHNode(); node-locked.store(true, std::memory_order_relaxed); CLHNode* prev tail.exchange(node, std::memory_order_acq_rel); node-prev prev; while (prev-locked.load(std::memory_order_acquire)) { _mm_pause(); } myNode node; } void unlock() { myNode-locked.store(false, std::memory_order_release); delete myNode-prev; myNode nullptr; } private: struct CLHNode { std::atomicbool locked; CLHNode* prev; }; std::atomicCLHNode* tail; CLHNode dummy; static thread_local CLHNode* myNode; }; thread_local CLHLock::CLHNode* CLHLock::myNode nullptr;这个版本每次加锁都new一个节点解锁时delete前驱节点。注意delete的是前驱而不是自己因为自己的节点可能还被后继读着。这个设计巧妙地避免了节点复用问题但代价是频繁的内存分配。5.2 节点复用与内存管理优化频繁new/delete在高性能场景下是不可接受的。优化的思路是用一个thread_local的节点池每个线程维护两个节点交替使用。或者更简单每个线程只维护一个节点但解锁时不立即复用而是等下一次加锁时再用。class CLHLockOpt { public: void lock() { CLHNode* node nodes[currIdx]; node-locked.store(true, std::memory_order_relaxed); CLHNode* prev tail.exchange(node, std::memory_order_acq_rel); node-prev prev; while (prev-locked.load(std::memory_order_acquire)) { _mm_pause(); } currIdx ^ 1; } void unlock() { CLHNode* node nodes[currIdx ^ 1]; node-locked.store(false, std::memory_order_release); } private: struct CLHNode { std::atomicbool locked; CLHNode* prev; }; static thread_local CLHNode nodes[2]; static thread_local int currIdx; std::atomicCLHNode* tail; };用两个节点交替保证解锁时用的节点和加锁时用的节点不是同一个这样后继线程读到的还是有效的状态。这个方案避免了动态内存分配性能提升明显。5.3 缓存行对齐的实际处理前面提到节点要做缓存行对齐实际代码里可以这样写struct alignas(64) CLHNode { std::atomicbool locked; CLHNode* prev; char padding[64 - sizeof(std::atomicbool) - sizeof(CLHNode*)]; };但要注意alignas(64)只保证结构体起始地址对齐如果结构体大小不是64的倍数数组里相邻元素的locked还是可能共享缓存行。所以padding是必须的。另外tail指针本身也可能和其他变量共享缓存行高竞争场景下也要对齐。5.4 完整可运行示例与测试把上面的片段拼起来写一个完整的测试程序用多个线程递增一个计数器验证锁的正确性和性能。#include atomic #include thread #include vector #include iostream #include chrono class CLHLock { // ... 上面的实现 }; std::atomiclong long counter{0}; CLHLock lock; void worker(int iterations) { for (int i 0; i iterations; i) { lock.lock(); counter.fetch_add(1, std::memory_order_relaxed); lock.unlock(); } } int main() { const int numThreads 8; const int iterations 1000000; std::vectorstd::thread threads; auto start std::chrono::high_resolution_clock::now(); for (int i 0; i numThreads; i) { threads.emplace_back(worker, iterations); } for (auto t : threads) t.join(); auto end std::chrono::high_resolution_clock::now(); auto ms std::chrono::duration_caststd::chrono::milliseconds(end - start).count(); std::cout counter counter.load() , time ms ms\n; return 0; }实测下来八线程各一百万次递增用CLH锁大概在几百毫秒量级具体取决于硬件。如果换成简单的atomic_flag自旋锁时间会明显更长线程越多差距越大。6. CLH与其他锁的对比与选型建议6.1 CLH vs MCS两种队列锁的取舍MCS锁是另一种经典的队列锁和CLH正好互补。MCS锁是显式队列每个线程在自己的节点上自旋前驱释放时修改后继节点的状态。CLH是隐式队列每个线程在前驱节点上自旋。特性CLH锁MCS锁自旋位置前驱节点自己节点队列维护隐式只需tail显式需要head和tailNUMA友好度较差跨节点访问前驱较好本地自旋超时取消难实现较易实现内存占用每线程一个节点每线程一个节点在NUMA架构上MCS通常表现更好因为线程在自己本地节点上自旋不需要跨节点访问前驱。CLH在NUMA上可能会有远程访问的开销。但CLH的实现更简单入队出队不需要维护head指针。6.2 CLH vs 简单自旋锁什么时候值得用简单自旋锁在低竞争下性能很好因为它的加锁解锁就是一次CAS没有队列操作的开销。但竞争一上来缓存行颠簸就会让它迅速退化。经验值是如果线程数超过四个且临界区很短CLH就开始显现优势。线程数越多优势越明显。但CLH也不是没有开销。每次加锁都要做一次exchange这是一次原子RMW操作比简单自旋锁的CAS略贵。而且每个线程要维护节点内存开销更大。所以如果竞争不激烈用简单自旋锁就够了没必要上CLH。6.3 实际项目中的选型决策树我一般按这个思路选临界区极短线程数少于四竞争低用简单自旋锁或atomic_flag。临界区短线程数多竞争激烈用CLH或MCS。NUMA架构对延迟敏感优先MCS。需要超时或取消用MCS或带超时的阻塞锁。临界区长用阻塞锁自旋锁都不合适。这个决策树不是绝对的实际还要看具体硬件和负载特征。最好的办法是压测用数据说话。7. 常见问题与排查技巧实录7.1 死锁与活锁的排查思路CLH锁本身不容易死锁因为它的等待关系是一条链不会成环。但活锁是可能的如果内存序用错可能导致线程永远看不到前驱的释放。排查方法是检查所有原子操作的内存序确保release和acquire配对。另外如果节点复用了但没处理好可能导致状态错乱表现为线程卡死。我遇到过一次原因是解锁时用了relaxed store后继线程的acquire load看不到这个修改一直自旋。改成release就好了。这种问题在x86上可能不明显因为x86的store本身就有release语义但换到ARM上就暴露了。7.2 性能不达预期的常见原因CLH锁性能不达预期最常见的原因是伪共享。如果节点没对齐或者tail指针和其他热点变量共享缓存行性能会大打折扣。用性能分析工具看缓存未命中率如果很高基本就是这个问题。第二个原因是自旋时没加pause指令导致CPU功耗高超线程互相干扰。第三个原因是节点分配用了动态内存malloc本身有锁在高并发下成为瓶颈。用thread_local节点池可以解决。7.3 内存序错误的典型表现内存序错误的表现很隐蔽可能测试跑一万次都对第一万零一次出错。典型表现是临界区里的修改偶尔丢失或者锁偶尔失效。排查方法是把内存序全部改成seq_cst如果问题消失说明是内存序问题然后逐个改回relaxed/acquire/release找到出错的那个。注意内存序问题不要靠猜要用工具。ThreadSanitizer可以检测数据竞争虽然对原子操作的支持有限但能发现大部分问题。7.4 高频问题速查表问题现象可能原因解决方法线程卡死内存序错误release/acquire未配对检查并修正内存序性能随线程数下降伪共享节点缓存行对齐CPU利用率过高自旋无pause加pause/yield指令偶发数据丢失解锁store用了relaxed改为release内存分配成为瓶颈动态new/delete用thread_local节点池NUMA上延迟高跨节点访问前驱考虑改用MCS锁8. 进阶话题与工程实践建议8.1 在NUMA架构上的适配NUMA架构下CLH锁的前驱节点可能分配在远程节点上自旋时的load会走远程内存延迟高。适配的方法有两种一是把节点分配在本地节点但前驱指针还是指向远程二是改用MCS锁让线程在本地节点自旋。实际工程中如果确定部署在NUMA环境MCS往往是更好的选择。8.2 与条件变量结合的思路CLH锁是纯自旋的不支持等待条件。如果需要条件等待可以在CLH锁之上再包一层用条件变量做阻塞。但这样会引入上下文切换开销适合临界区长且等待时间不确定的场景。实现时要注意条件变量的等待和唤醒要在CLH锁的保护下进行避免丢失唤醒。8.3 实际项目中的调优经验我在实际项目里用CLH锁有几个经验。第一节点池的大小要合适太小会导致频繁分配太大浪费内存。一般每个线程两个节点就够了。第二pause指令的次数要调太少起不到省电作用太多增加延迟。一般几十到几百次比较合适。第三压测时要模拟真实负载不要只用空临界区空临界区下CLH的优势不明显真实负载下才能看出差距。最后分享一个小技巧如果发现CLH锁在某个场景下性能不好先别急着换锁用性能分析工具看看瓶颈到底在哪。很多时候问题不在锁本身而在临界区里的其他操作比如内存分配、系统调用。把那些优化掉锁的性能自然就上来了。