上一篇文章吐槽了信号量，结论是：互斥场景下，别用信号量，用mutex。

mutex到底好在哪里？它内部是怎么实现的？为什么一个看似简单的lock/unlock，内核代码会变得那么复杂？mutex今天的复杂模样，其实是从一个极简设计一步步‘卷’出来的。

一、为什么需要 mutex？

多核处理器上，多个 CPU 同时访问共享资源时，必须保证同一时刻只有一个 CPU 进入临界区。

最直接的方案是自旋锁（spinlock）：

CPU0：拿到锁 → 进入临界区 → 释放锁CPU1：一直循环检查锁是否被释放（忙等）

自旋锁的问题：如果临界区代码执行时间较长（比如几十微秒），CPU1 就会白白空转。

mutex（互斥锁）的设计目标：当锁被持有时，让等待者睡眠，把 CPU 让给其他任务。等锁释放时，再唤醒等待者。

核心原则：临界区极短且无睡眠风险的场景适合自旋锁；临界区较长或存在调度风险的场景用 mutex。

本文讨论的 mutex 复杂设计均为多核场景服务，单核场景下不存在真正的并行冲突。

二、简史：从信号量到 mutex 的四次演进

mutex的演进有几个关键节点，下面简单介绍这几个关键节点，可以帮助理解mutex为何这么设计以及为何会变得那么复杂。

第一次：mutex 正式诞生

上一篇文章我们吐槽了信号量没有owner、语义模糊、调试困难。其实除了这些架构层面的缺陷，信号量在性能上也有硬伤——早期内核用信号量（初始值设为1）来模拟互斥锁，结果每次加锁解锁都要走一遍信号量的慢速路径。

所以Ingo Molnar 在2006引入了专门的 struct mutex，核心改进是：

• 无竞争时只需一次原子操作（在 x86 上为 cmpxchg 指令），直接标记锁被持有

• 有竞争时才进入等待队列处理

这就是快速路径（Fast Path）的雏形。mutex 从此成为独立的数据结构。

第二次：加入乐观自旋

第一代 mutex 在锁争用时直接让等待者睡眠。这在临界区较长时没问题，但如果临界区很短（比如只修改一个变量），睡眠唤醒的开销远大于自旋等待的代价。一次睡眠和唤醒不仅涉及上下文切换，还会导致 CPU 缓存失效，其时间成本可能高达数十微秒甚至更多，而短暂的自旋（如果锁很快释放）则小得多。

因此引入了乐观自旋（Optimistic Spinning）：如果锁被持有但持有者正在另一个 CPU 上运行，等待者短暂自旋而非直接睡眠。这就是中速路径的雏形。（具体实现见第三、四章）

第三次：引入 MCS 排队

引入乐观自旋后，新的问题出现了：如果多个 CPU 同时自旋等待同一个锁，它们会反复读取同一个内存地址（锁变量），导致 CPU 缓存行在多个核之间不停 "弹来弹去"—— 这叫缓存颠簸（Cache Bouncing），多核扩展性急剧下降。

解决方案是 MCS 锁机制：每个 CPU 在自己的本地变量上自旋，避免争抢同一个内存地址，锁在队列中逐个传递。（具体排队机制见第四章）

第四次：状态编码重构

2016 年，Peter Zijlstra 将 owner 指针与 WAITERS/HANDOFF/PICKUP 三个标志位合并存储于一个原子长整型中，利用指针低位编码状态，消除了 owner 指针与状态标志之间的一致性问题，使得在无锁情况下也能安全地判断是否有等待者，为后续公平性机制奠定了基础。

演进全景图

三、mutex 的核心设计：三条路径

mutex 会根据不同的场景选择不同的处理方式，分为快、中、慢三个路径：

                  ┌─────────────┐                  │ 尝试获取锁   │                  └──────┬──────┘                         │                   锁是否空闲？                    │      │                  是│      │否                    ▼      ▼            ┌─────────┐  ┌─────────────┐            │ 快速路径 │  │ 持有者是否  │            │ 直接获得 │  │ 正在运行？  │            └─────────┘  └──────┬──────┘                                │                          是│   │否                            ▼   ▼                    ┌──────────┐ ┌──────────┐                    │ 中速路径 │ │ 慢速路径 │                    │ 乐观自旋 │ │ 睡眠等待 │                    └──────────┘ └──────────┘

快速路径（Fast Path）

锁没有被任何人持有。通过一条原子操作指令将锁标记为 "当前进程持有"，立即返回。

中速路径（Mid Path / Optimistic Spinning）

如果持有锁的进程在另一个 CPU 上运行。则乐观自旋，等待合适时机退出自旋。 同时为了解决缓存颠簸问题，乐观自旋使用MCS排队机制。

乐观自旋不是傻等，它有一套退出机制。只有"持有者正在另一个CPU上运行且很快会释放锁"时，自旋才有价值。其他情况，等下去没有意义：

慢速路径（Slow Path）

慢速路径发生在乐观自旋失败或不适用的场景——比如持有者已经不在运行状态。这时当前进程把自己加入等待队列，设置WAITERS标志，然后调用schedule()让出CPU。等锁释放时，队首的等待者会被唤醒，醒来后重新尝试获取锁。

这个流程的代价是上下文切换加上唤醒延迟，几十微秒起步，所以只有在自旋确实不值得的时候才会走这条路。

设计权衡

快速路径就一条原子指令，几纳秒的事；中速路径自旋几个微秒；慢速路径上下文切换，几十微秒起步。数量级差这么多，所以必须分路径处理。

四、乐观自旋的精髓：MCS 排队机制

4.1 为什么需要排队？

如果多个 CPU 同时在自旋等待同一个锁，它们会反复读取同一个内存地址 —— 锁变量。这会导致：

1. CPU 缓存行在多个核之间 "弹来弹去"
2. 内存总线拥堵
3. 性能急剧下降

这叫做缓存颠簸。

4.2 MCS 锁的核心思想

每个 CPU 在自己的本地变量上自旋，而不是在全局锁变量上。

打个比方：

• ❌ 老方案：10 个人都盯着门口的一盏灯，灯一变绿就冲进去（所有人都看同一个地方，缓存行不停搬家）。

• ✅ MCS 方案：10 个人排成一队，每个人都只盯着前一个人的后脑勺（自己本地的缓存行），前一个人转头告诉你 "该你了"。

缓存行只在前驱和后继之间传递，不波及所有人。

4.3 排队的过程示意图

时间 →CPU0: [持锁] ────────────────→ [释放锁，修改CPU1的标志位]                                   │                                   ▼CPU1:        [排队] → [自旋等待CPU0] → [拿到锁] → [释放锁，修改CPU2的标志位]                                                       │                                                       ▼CPU2:               [排队] → [自旋等待CPU1] → [拿到锁]

关键机制：

1. 想拿锁的人，先取一个 "排队号"，挂到队列尾部

2. 如果前面没人排队，直接获得 MCS 锁，开始自旋

3. 如果前面有人，自旋等待前驱节点释放

4. 前驱释放时，通知后继节点（MCS 锁在队列中逐个传递）

MCS锁第一次看确实会觉得有点绕——每个CPU在自己的本地变量上自旋，而不是盯着全局锁。但想想多核场景下缓存一致性协议的开销，这个设计其实是必然的选择。

五、总结：mutex 的设计哲学

看完mutex的设计，答案其实很直白：

信号量是什么都想干（互斥、计数、同步），但哪样都干得不够好。mutex反过来——我只干一件事（互斥），但把这件事做到极致。

为了“极致”，它引入了快速路径、自适应自旋、MCS排队、handoff交接……代码确实变复杂了，但换来的是：无竞争时几乎零开销，有竞争时尽可能减少上下文切换，大量CPU时还能避免缓存抖动。

说白了，mutex 复杂，是因为它要为了极致性能做各种优化；semaphore 看似简单，实则因为它身兼多职——既能当锁，又能做限流，还能发信号，场景一乱就容易翻车。

下篇直接看代码，看这些设计到底是怎么落地的。

往期推荐：