1. 并发编程困境：传统锁机制在高并发下的性能瓶颈
在多核 CPU 广泛普及的今天，并发编程已成为提升系统吞吐量的核心手段。然而，传统锁机制（自旋锁、读写锁）在高并发场景下暴露出严重的性能问题，其根源在于 Cache 一致性协议 引发的 Cache bouncing 现象。本章将深入剖析这一困境，为后续引入 RCU 机制奠定基础。
1.1 传统锁机制的分类与工作原理
在 Linux 内核及高性能应用中，最常用的传统锁包括：
| 锁类型 | 核心机制 | 适用场景 | 主要开销 |
|---|---|---|---|
| 自旋锁 (Spinlock) | 忙等待（busy-waiting），线程在获取锁前持续循环检测 | 临界区极短，上下文切换成本高于自旋 | CPU 空转、Cache line 失效 |
| 读写锁 (RWLock) | 区分读/写模式，允许多个读者并发，写者独占 | 读多写少场景 | 读者与写者之间的公平性、Cache bouncing |
| 互斥锁 (Mutex) | 睡眠等待，线程阻塞后让出 CPU | 临界区较长，允许线程切换 | 上下文切换开销、调度延迟 |
关键认知： 自旋锁和读写锁在高并发下的主要瓶颈并非锁本身的指令开销，而是由锁变量引发的 Cache 一致性流量。
1.2 Cache bouncing：被忽视的性能杀手
现代 CPU 采用多级缓存架构（L1/L2/L3），每个核心拥有私有缓存。当多个核心同时访问同一内存地址（如锁变量）时，MESI 协议（或衍生协议）会强制缓存行在核心间传递所有权，导致以下问题：
- 缓存行失效： 核心 A 修改锁变量后，核心 B 的缓存行被标记为 Invalid，必须从内存或核心 A 重新读取。
- 总线风暴： 大量缓存一致性消息在系统总线上传播，挤占内存带宽。
- 性能退化： 随着核心数增加，锁获取延迟呈非线性增长，甚至出现 锁争用风暴。
1.3 自旋锁的 Cache 一致性开销
自旋锁的实现通常依赖原子操作（如 x86 的 lock cmpxchg），每次尝试获取锁都会：
- 原子读-改-写： 修改锁变量，触发缓存行所有权转移。
- 广播失效： 所有其他核心的缓存行副本被标记为 Invalid。
- 重试风暴： 释放锁时，所有等待核心同时尝试获取，导致 惊群效应（thundering herd）。
性能数据（参考）： 在 64 核 ARM 处理器上，一个简单的自旋锁在高度争用下，锁获取延迟可达 数百纳秒，而临界区执行本身可能仅需 10-20 ns。锁开销占比超过 90%。
1.4 读写锁的伪共享问题
读写锁虽然允许多个读者并发，但在实际实现中，读者计数器通常位于同一缓存行。当多个读者同时递增计数器时，即使没有写者，也会发生 伪共享（False Sharing）：
- 读者 A 修改计数器 → 核心 A 的缓存行变为 Modified。
- 读者 B 修改计数器 → 核心 B 必须从核心 A 获取最新缓存行。
- 即使逻辑上读者之间不互斥，硬件层面仍产生大量一致性流量。
1.5 传统锁的扩展性瓶颈
随着核心数增加，传统锁的吞吐量往往不升反降。以下是一个典型测试结果（临界区为简单计数器递增）：
| 核心数 | 自旋锁吞吐量 (ops/s) | 读写锁吞吐量 (ops/s) | 理想线性扩展 |
|---|---|---|---|
| 1 | 100 M | 100 M | 100 M |
| 4 | 120 M | 150 M | 400 M |
| 8 | 80 M | 110 M | 800 M |
| 16 | 45 M | 60 M | 1.6 G |
| 32 | 20 M | 25 M | 3.2 G |
核心结论： 传统锁的扩展性在 8 核后出现明显拐点，16 核后性能甚至低于单核。Cache bouncing 是导致这一现象的根本原因。RCU 正是为解决此问题而设计——它允许读者完全无锁访问，彻底消除读路径上的缓存一致性流量。
1.6 从困境到出路：RCU 的设计哲学
面对传统锁的困境，RCU（Read-Copy-Update）采取了截然不同的策略：
- 读者无锁： 读者不需要获取任何锁，也不需要原子操作，直接读取共享数据。
- 写者延迟回收： 写者创建新副本，通过指针切换发布更新，并等待所有已有读者完成后才回收旧数据。
- 免同步读取： 读者路径上无 Cache bouncing，性能接近纯内存读取。