悟无误我接手过一个优化任务，说穿了很简单：一份配置，64 个线程几乎不停地在查，只有一个线程偶尔改一次，标准的读多写少。第一版实现我图省事，直接用 pthread_rwlock_t，写者拿写锁，读者拿读锁。压测一跑，心里凉了半截：随着并发线程增加，吞吐量涨到某个点以后不升反跌，而且读线程之间明显在互相等待。
后来用 perf 追下去，发现业务代码本身干净得很，热点全在锁函数上。那次我才真正意识到，并发与竞态条件的问题不是“加个锁”就能收工，不同场景对同步原语的要求完全不一样。也是从那时起，我开始认真啃内核社区常用的 Read-Copy-Update，也就是常说的 RCU，读-拷贝-更新。这篇文章把当时爬过的坑、验证过的思路、写用户态代码需要注意的事一起讲清楚。
1. 读写锁为什么会在“读多写少”场景输掉
1.1 我碰到的一次锁争用瓶颈
先说那个具体案例。程序里有一张哈希表，用来保存设备 ID 到转发路径的映射，查询频率是每秒几十万次，更新频率低到可以忽略。一开始我用一个 pthread_rwlock_t 保护整张表：读者加读锁后查表，更新者加写锁后替换整张表。从 API 语义上看，这完全符合直觉——多个读者应该可以并行读，只有写者才需要独占。
压测环境是双路服务器，总共 48 个逻辑核。我用 48 个线程死循环查询，单线程每秒能查 1200 万次，但线程数到 32 时，总吞吐量反而只有 1800 万次左右。按理说读锁应该允许所有读者并行进入，为什么核越多反而越慢？
perf top 的结果给出了答案：排在最前面的不是哈希函数，也不是业务逻辑，而是 __pthread_rwlock_rdlock 和 __pthread_rwlock_unlock。用户态读写锁在读者路径上并不是零开销，所有读者都在围绕锁计数器的同一个缓存行做原子操作，这个隐藏的全局同步点让“并行读”变成了“排队抢计数器”。
1.2 读者之间也会互相阻塞的物理原因
说到原子操作，很多人觉得一条原子指令很便宜，几十纳秒而已。但在多核场景下，问题的关键不是指令本身，而是缓存一致性协议。多个 CPU 同时修改同一个内存地址时，这个地址对应的缓存行会在各 CPU 的 L1/L2 之间反复失效、重传。
打个比方，就是把所有读者都集中到一间屋子里，每次进门都要在一本签到簿上写名字。签到只是个简单动作，但几十个人同时伸手去抢同一支笔，大部分时间都花在“等前一个人把笔递过来”上。读写锁的读计数器就是那本签到簿，读者的并行性被硬件缓存行颠簸给串行化了。
RCU 的思路完全不同：它尽量让读者路径上不出现任何共享计数器。读者不需要告诉别人“我在读”，只需要在某一个极短的临界区里读一个指针，临界区长度可以被压到几十条指令以内。读路径上没有原子 RMW 操作，没有锁，缓存行没有被多核写入，自然也不会互相干扰。
1.3 读写锁公平策略带来的隐藏延迟
另一个容易忽略的点是，现代读写锁（包括 glibc 的 pthread_rwlock_t）为了实现公平，加了写者偏好或者排队机制。一旦有写者在等待，新来的读者可能被挡在读锁外面，避免写者饿死。这本身是好事，但对高并发读的热路径来说，可能会出现“一个低频写者让一大群读流量瞬间停顿”的现象。
在我那个场景里，更新操作非常少，可只要更新线程序在持锁，几十个读者线程会立刻被卡在同一把锁上，更新完以后它们还要在锁计数器的缓存行上重新“抢位置”。一次写操作引发一次全局停顿，这种锯齿状的延迟节奏对读吞吐伤害很大。
所以结论是：不是读写锁设计错了，而是它在“读者特别多、临界区特别短”的场景下，锁本身的放大效应超过了数据竞争的代价。想让读者彻底解放，需要一种连读锁都不需要的方案，RCU 恰好就是冲着这个诉求来的。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. RCU 的工作模型：读不锁，写则拷贝，旧版晚点回收
2.1 读-拷贝-更新，名字已经把答案说清楚
RCU 的全称是 Read-Copy-Update，三个单词直接描述了写者的动作。读者在读一个共享对象时，不需要拿任何锁；写者要修改对象时，不直接在原对象上改，而是先拷贝一份，在副本上完成修改，再把指向新对象的指针发布出去。等到所有可能还在读旧对象的读者都离开后，才把旧对象回收掉。
这个过程里，读者始终不知道背后发生了什么。它只是读了一次指针，拿到一个地址，然后使用这个地址指向的数据。如果此时新版本已经发布，它可能拿到新地址；如果新版本还没发布，它可能拿到旧地址。关键是无论拿到哪个，都是完整的、一致性良好的内存快照，而不是某个中间状态。
这个思路很反直觉。传统互斥锁是在“写之前加屏障，确保读者看不到半成品”，RCU 则是“不阻止你读，但保证你在任何时刻看到的一定是某个完整版本”。它把一致性维护从“锁住所有读者”变成了“数据副本 + 原子指针切换 + 延迟回收”。后者的读者代价几乎降为零。
2.2 发布与订阅：读者只会看到完整旧版或完整新版
我理解 RCU 时，印象最深的是一个概念：发布-订阅模式。写者把内存屏障放在“指针发布”这一步，读者通过特定的读操作去“订阅”指针。
具体说，写者在更新一个结构体字段时，常规做法是：
c复制obj->key = new_key;
obj->value = new_value;
obj->refcnt = 1;
ptr = obj; // 把指针“发布”出去
如果在这之前有读者读到了旧指针，它后续读到的还是同一块内存，不受影响。如果有读者在发布后才读指针，它读到的是新对象，而新对象里的字段已经全部设置好了。问题在于编译器和 CPU 都可能打乱指令顺序，可能把 ptr = obj 之前的数据写入挪到后面去，也可能让读者在发布前就提前读取并推测执行。所以 RCU 要求写者使用类似于 rcu_assign_pointer 的 release 语义操作来发布指针，读者则必须使用 rcu_dereference 的 acquire 语义操作来读指针。
如果你用过 C++ 的 std::atomic，可以把这理解成 store(release) 和 load(acquire) 的组合。没有这一层，光靠“先写字段再放指针”的代码直觉是远远不够的。
2.3 写者之间仍然需要一把“小锁”
值得强调一下，RCU 并不保证写者之间能并行。两个写者同时拷贝、发布到同一个指针，结果只能有一个胜出，另一个的修改会丢失。所以实际工程里，写者之间通常还是需要一把互斥锁来串行化更新。
这不算缺陷。RCU 的设计目标很清楚：把写者的竞争成本移出读路径。读路径上无锁，写路径上该串行的还是串行。大量实际场景里写频率本来就低，写者之间好商量，读者流畅才是重点。那些更新非常频繁、每秒几万次以上的场景，本来就不太适合用 RCU。
3. 宽限期：旧数据什么时候才允许被回收
3.1 从“旧值没人用”到“静止状态”
RCU 最核心的问题不是“怎么发布新指针”，而是“怎么知道该把旧指针释放了”。想理解这个问题，可以从引用计数的角度去对照。
一种朴素的回收方式是记录每个读者在读，等读者数量归零再释放。这在读特别多时会带来和读写锁一样的计数争用，不可取。RCU 换了一种方式：它不去实时统计“当前有几个读者在读旧版本”，而是等待所有 CPU 或所有线程经历一次“静止状态”。
什么叫静止状态？在 Linux 内核语境里，可以粗略理解成一次上下文切换。读者在进入 RCU 读临界区后，如果期间不睡眠、不让出 CPU，那么只要某个 CPU 上发生了一次上下文切换，就说明此前进入读临界区的读者已经离开了。因为读者如果还没读完，它不会主动让出 CPU 去执行调度器；调度本身就是它离开临界区的证据。
因此，写者调用 synchronize_rcu() 时做的事情大致是：等系统中的每个 CPU 都至少经历一次静止状态。全都经历过后，旧对象就可以安全释放了。这段等待时间就是宽限期（Grace Period）。
3.2 读者在临界区里为什么不能睡眠
既然宽限期依赖上下文切换来判断读者离开，那读者就绝对不能干会触发上下文切换的事。在内核里，传统 RCU 读临界区不能睡眠，不能调用可能阻塞的函数，不能做任何会导致本 CPU 被调度走的事。否则会发生非常隐蔽的内存错误：读者在临界区里被切换出去，调度器看到这个 CPU 产生了一次上下文切换，以为所有读者都离开了，于是宽限期结束，旧对象被释放；等读者被调度回来继续访问旧对象的时候，它已经在访问一块已释放的内存。
用户态 liburcu 虽然实现机制略有不同，但精神一致：读临界区必须尽量短，不能在里面做阻塞操作。我在实际使用中给自己定了一条规矩：RCU 读临界区里只做指针获取、简单字段读取，最多做一次字典查找，绝对不放日志、不加锁、不调用可能睡眠的库函数。
3.3 发布订阅之外还有一层内存屏障
传统锁保护共享数据时，锁本身自带内存屏障，能保证临界区内外的可见性。RCU 没有读者锁，所以这层屏障必须由发布和接收指针的宏来承担。
写者发布侧的屏障比较好理解。它需要保证“结构体字段写入”不会越过“指针发布”，否则读者读到一个半初始化对象。读者接收侧的屏障则是为了保证，拿到指针后对指针指向内容的读取不会被 CPU 或编译器重排到读指针之前。否则可能出现一种诡异的乱序：读者还没加载指针，CPU 就把后续的数据读取提前执行了，读到的还是旧内存内容，而旧内存此刻可能已经在回收流程里。
实现这层逻辑，内核里常用 smp_store_release 和 smp_load_acquire 这两个基本原语，RCU 的指针发布宏在此基础上做了一层语法封装。用户态则要看工具库封装好了的内存屏障指令。很多第一次接触源码的开发者看到 rcu_dereference() 里那么多条件编译和屏障宏，会觉得很夸张。但只要理解了多核内存模型，就知道这不是过度防御，而是平衡正确性与性能的必然结果。
3.4 宽限期的成本实际由写者承担
从读路径看，RCU 极快。但从写路径看，一次 synchronize_rcu() 可能要等待毫秒级甚至更久，因为要等所有核都经历一次调度。写者付出的代价是极高的，更新频率一旦超过某个阈值，这个等待就会成为新瓶颈。
把两种同步方式的成本结构摆在一起看，定位就特别清晰：
| 维度 | 互斥锁/读写锁 | RCU |
|---|---|---|
| 读者进入临界区 | 可能有原子操作和锁等待 | 接近零，通常只是一次禁抢占和屏障 |
| 读者互相影响 | 高并发时受缓存行颠簸影响 | 几乎不互相影响 |
| 写者更新 | 修改很快，但会阻塞所有读者 | 需要拷贝、发布，并等待宽限期 |
| 新版本可见性 | 写者释放锁后 | 指针发布后 |
| 旧版本回收 | 随锁释放自然完成 | 宽限期结束后显式回收 |
结论很清楚：如果你的场景是读路径极其敏感、写者少且能容忍延迟，RCU 很合适；反过来，写者频率高、读者少，那它远不如普通锁直接。
4. 内核中的 RCU 并不只是实验室玩具
4.1 从全局广播到树状汇总
最早的内核 RCU 实现很简单：维护一个全局状态，每个 CPU 经历静止状态后就上报。CPU 数量少时这没什么问题，可当服务器到了上百核、几百核，全局广播和汇总会变成扩展性瓶颈。现代内核把全局结构改成了树形结构，每个 CPU 对应一个叶子节点，叶子节点向父节点汇总状态，逐层上报到根。这就是 Tree RCU。
树状结构的价值在于，等待宽限期时不再需要全局横扫每个 CPU。一个节点只需要知道它这一组 CPU 是否都已经经历静止状态，然后向上一层传递一个聚合结果。CPU 数量增多后，同步的消息量和汇总开销增长得可控。对于写者极少的内核子系统，等待宽限期的绝对时间并不会因为 CPU 核数增加而产生灾难性影响。
读侧的实现也做了精细区分。在非抢占内核里，读者临界区几乎不产生额外代码；在可抢占内核里，读者进入临界区需要禁用当前 CPU 的抢占。这解释了为什么 RCU 读者能快到那种程度——它没有把“禁抢占”做成锁那样复杂的公共操作。
4.2 异步回收 call_rcu 与回调风暴
如果每次更新都直接调用 synchronize_rcu()，那么写路径会被宽限期阻塞很久，很多内核子系统无法接受这个延迟。因此内核又提供了 call_rcu() 这种异步接口。写者把旧对象的回收函数注册到回调队列，RCU 子系统在宽限期结束后批量执行这些回调。
异步回调的思路很像延迟垃圾回收：更新可以瞬间完成，内存释放被推迟到安全时机。但它也带来新的问题。如果更新频率太高，而旧对象回收延迟又长，回调队列里会积压大量待释放对象，内存占用持续上升，甚至触发“回调风暴”。这类问题在实际生产环境里并不罕见，解决办法通常是降级更新频率，或者在确实有必要时主动调用 rcu_barrier() 等待队列清空。
4.3 为特殊读者准备的 SRCU 与 tasks-RCU
传统 RCU 读者不睡眠这个限制太苛刻，很多内核组件需要在读临界区里等待、异步处理。于是内核提供了 SRCU（Sleepable RCU）。它的读临界区里可以睡眠，代价是读者进出临界区需要执行更多原子操作和状态维护，开销比传统 RCU 高不少，但也远好于全局互斥。
还有应对线程生命周期问题的 tasks-RCU，它等待的目标不是 CPU 经历一次调度，而是系统中所有任务都经历一次状态转换。不同变体背后的基本思想是一致的：确定一个“每个人都经过检查点”的时刻，然后安全回收旧资源。
我刚开始接触这些变体时也容易绕晕，后来我把它们理解成不同粒度的宽限期模型：一类以 CPU 调度的粒度判断，一类以任务状态切换的粒度判断，还有一类用在阻塞场景下以更长等待换安全性。内核根据场景选择最合适的模型。
4.4 内核里为什么仍保留普通锁
讲到这里也许有人会问：如果 RCU 这么好，为什么不把所有锁都换成 RCU？原因在于不仅写路径代价高，而且 RCU 无法覆盖所有共享数据场景。两个写者频繁更新同一个可变对象时，RCU 的拷贝和宽限期成本会让人无法接受；读者需要非常精确地实时看到最新值时，RCU 的多版本快照语义也可能不满足业务需求。
内核里仍然大量使用自旋锁、互斥锁、读写锁。RCU 的最佳位置是那些“数据结构被大量读者频繁访问，更新极少，且可以接受旧版本短暂残留”的场合。链路表、路由表、权限配置这类数据特别适合。离开这个场景去硬套 RCU，跟拿扳手拧螺丝没有本质区别。
5. 用户态实操：用 liburcu 写一个全局配置发布器
5.1 用户态复刻内核思想为什么绕路
内核可以直接感知 CPU 状态和任务调度，但用户态程序做不到。普通应用线程被调度器切走时，进程本身并没有一个可靠的“此刻该线程不可能再访问旧数据”的通知。
liburcu 解决这个问题的思路很有趣。它让每个使用 RCU 的线程维护一个本地状态，标记自己是否处于读临界区。宽限期开始后，写者通过 membarrier 系统调用或其他手段，观察所有注册线程的状态。只有当一个线程已经不再位于读临界区时，才认为它经历了一次静止状态。如果某个线程一直在线但不退出读临界区，写者就得一直等。所以读临界区短、线程能及时退出，是用户态 RCU 正常工作的前提。
这个模型比内核更依赖线程显式配合，因此在使用 liburcu 的程序里，“注册线程”不是可选项。你的线程要在入口注册，在退出前反注册，否则宽限期可能无法正确判断它的状态。
5.2 选择哪种 liburcu flavor
liburcu 提供了不同 flavor，它们的区别主要在“如何迫使其他线程进入一次可观察的状态”：
-lurcu-signal：利用信号打断目标线程来检测静止状态，读者线程不能被阻塞信号。读侧开销很低，但要求程序对信号处理比较配合。-lurcu-memb：基于membarrier系统调用，不依赖信号，对线程环境更友好，读侧开销也很低，适合大多数普通服务程序。-lurcu-mb：用完整内存屏障实现，语义最简单，读侧开销相对高。-lurcu-bp：不要求显式注册线程，适合动态库、无法控制线程生命周期的场景，但读者路径更重。
如果是从零写一个新服务，我建议优先考虑 membarrier 版本或默认库。它少了信号处理那一层额外约束，线程模型更干净。下面的示例按默认 liburcu 的通用接口写，不同 flavor 的宏前缀略有区别，但思想一致。
5.3 最小可运行示例
下面代码演示如何用 liburcu 实现一个只读的配置对象发布。这个例子做了简化：只替换一个指向配置结构体的指针。
c复制#include <urcu.h>
#include <stdio.h>
#include <stdlib.h>
struct config {
int version;
int timeout_ms;
int retries;
};
static struct config *g_cfg;
void init_config(void)
{
struct config *cfg;
cfg = calloc(1, sizeof(*cfg));
cfg->version = 1;
cfg->timeout_ms = 100;
cfg->retries = 3;
rcu_assign_pointer(g_cfg, cfg);
}
void *reader_thread(void *arg)
{
long id = (long)arg;
urcu_register_thread();
for (int i = 0; i < 1000000; i++) {
int timeout_ms;
struct config *cfg;
urcu_read_lock();
cfg = rcu_dereference(g_cfg);
timeout_ms = cfg->timeout_ms;
urcu_read_unlock();
if (i == 0)
printf("reader %ld sees timeout=%d\n", id, timeout_ms);
}
urcu_unregister_thread();
return NULL;
}
void update_config(int new_timeout)
{
struct config *old_cfg;
struct config *new_cfg;
/* 写者之间也需要互斥，示例省略 */
new_cfg = calloc(1, sizeof(*new_cfg));
new_cfg->version = 2;
new_cfg->timeout_ms =