1. RCU背景与动机：多核时代锁竞争问题、读写锁的局限性、RCU的设计哲学与无锁读路径
1.1 多核时代的锁竞争危机
随着摩尔定律在频率上的失效，处理器架构全面转向多核/众核。Linux内核作为全球最大的并行软件系统之一，在SMP（对称多处理）环境下，锁竞争成为性能扩展的主要瓶颈。
核心矛盾：当CPU核心数从2核增长到128核，传统自旋锁的争抢概率呈O(n²)增长，导致大量CPU时间浪费在缓存一致性协议（MESI）的缓存行 bouncing 上。
以下表格展示了不同同步机制在多核环境下的关键差异：
| 同步机制 | 读者与读者 | 读者与写者 | 写者与写者 | 扩展性瓶颈 |
|---|---|---|---|---|
| 自旋锁（spinlock） | 互斥 | 互斥 | 互斥 | 所有核心 |
| 读写锁（rwlock） | 共享 | 互斥 | 互斥 | 写者饥饿 + 缓存行 bouncing |
| RCU | 无锁 | 无等待 | 互斥（可延迟） | 仅写者间 |
1.2 读写锁的局限性
读写锁（rwlock）允许多个读者并发，但读者与写者之间仍然互斥。在“读多写少”的场景下，读写锁看似比自旋锁高效，但存在三个致命缺陷：
- 写者饥饿：持续不断的读者流可能使写者无限期等待。
- 缓存行 bouncing：读者获取锁时仍需要原子操作修改锁变量，导致所有读者核心的缓存行失效。
- 不可扩展：在数百核的系统中，即使只有读操作，锁变量的缓存一致性流量也会耗尽内存带宽。
性能陷阱：在200+核的ARM服务器上，一个全局读写锁的读路径延迟可能比实际数据访问延迟高出10~100倍，因为所有读者都在争抢同一个缓存行。
以下对比展示了读写锁与RCU在读路径上的本质差异：
| 指标 | 读写锁（rwlock） | RCU |
|---|---|---|
| 读者是否需要原子操作 | 是（atomic_add / atomic_sub） | 否（仅需屏障指令） |
| 读者是否修改共享变量 | 是（锁计数） | 否 |
| 读者间是否产生缓存一致性流量 | 是（频繁） | 否（零） |
| 写者等待读者 | 是（写者必须等待所有读者释放） | 是（但等待的是宽限期，而非锁） |
| 读者延迟抖动 | 高（受锁竞争影响） | 极低（确定性） |
1.3 RCU的设计哲学：无锁读路径
RCU（Read-Copy-Update）的核心思想是：读者绝不阻塞，写者通过“延迟回收”来保证安全性。其设计哲学可以概括为三条原则：
- 读者无锁：读者访问共享数据时，不需要获取任何锁，也不需要执行原子加法或CAS操作。读者只需要保证读取操作的原子性（通过内存屏障）。
- 写者复制更新：写者不直接修改共享数据，而是先复制一份副本，在副本上完成修改，然后通过原子指针更新将新版本发布出去。
- 延迟回收：旧版本数据不能立即释放，必须等待所有正在访问旧版本的读者完成（即“宽限期”结束后），才能安全回收。
1.4 RCU的典型应用场景
RCU在Linux内核中广泛应用于以下子系统：
- 网络协议栈：路由表（FIB）、邻居表（ARP）、套接字查找。
- 文件系统：dcache（目录项缓存）、inode缓存、文件描述符表。
- 内存管理：mm_struct的RCU保护、vm_area_struct遍历。
- 内核事件通知链：notifier chain的注册与通知。
- 安全模块：LSM钩子函数的动态注册。
适用条件：RCU最适合“读路径极多、写路径极少、写操作可以容忍一定延迟”的场景。如果写操作频繁（超过读操作的10%），RCU的复制开销和宽限期等待可能反而降低性能。
1.5 无锁读路径的核心收益
RCU通过消除读者侧的锁竞争，带来了以下可量化的收益：
| 收益维度 | 具体表现 | 典型提升幅度 |
|---|---|---|
| 读路径延迟 | 无锁等待、无缓存行 bouncing | 降低 80%~99% |
| CPU利用率 | 读者不消耗锁管理指令 | 读密集型场景提升 2~10x |
| 扩展性 | 读者数量增加不增加锁开销 | 近乎线性扩展 |
| 实时性 | 读者不会被写者阻塞 | 确定性延迟保障 |
| 代码复杂度 | 读者侧只需 rcu_read_lock/unlock | 降低维护成本 |