一、为什么要重新聊聊“锁”

• 同一句 lock() 背后，可能是用户态的自旋、可能是内核态的休眠，也可能是混合策略；
• 同一把 mutex，在 Linux 与 Windows 下的实现天差地别；
• 同一段临界区，因为 CPU 缓存行、内存序、调度器差异，性能可以相差一个数量级。

二、硬件地基：缓存行、总线锁与 MESI

1. 缓存行
   现代 CPU 以 64 字节为单位读写内存。若多个变量落在同一缓存行，且被不同线程修改，就会触发“伪共享”——线程 A 只改自己的变量，却导致线程 B 的缓存行失效，B 不得不重新从内存加载。锁的本质是“让多个线程排队”，如果锁变量本身与业务数据在同一缓存行，就会出现“锁没争用，缓存却来回失效”的怪现象。解决办法是“对齐填充”：把锁变量单独放到一个缓存行，其余位置用占位填充，避免“误伤”。
2. 总线锁
   早期 CPU 提供 LOCK# 信号，锁定整个系统总线，保证“读-改-写”原子。缺点是其他核全部暂停，性能惨不忍睹。现代 CPU 把锁定粒度缩小到“缓存行”，通过 MESI 协议实现“缓存锁”，只要操作在同一缓存行，且核之间通过总线嗅探完成一致性即可，无需锁整个总线。
3. MESI 协议
   Modified、Exclusive、Shared、Invalid 四种状态，保证“一个缓存行在任意时刻最多只有一个核可写”。CAS（Compare-And-Swap）指令依赖 MESI 完成“比较”和“交换”的原子性；若缓存行处于 Shared 状态，CPU 会先 invalidate 其他核的副本，再提升到 Modified，完成写操作。理解 MESI，就能明白：为什么“无锁”算法仍需缓存行对齐，为什么“锁”变量本身也会成为热点。

三、内核层：互斥体、信号量、自旋锁、队列锁

1. 互斥体（mutex）
   内核态 mutex 包含“所有者线程、等待队列、自旋计数”三个字段。获取锁时，若无人持有，直接标记所有权；若已被持有，当前线程先自旋若干次，再挂起并加入等待队列。自旋是为了“短临界区”的快速路径；挂起是为了“长临界区”的节能路径。自旋次数、挂起策略、唤醒顺序由调度器决定，不同操作系统算法差异很大。
2. 信号量（semaphore）
   允许 N 个线程同时进入临界区。可以当“资源计数器”使用，例如限制“最多 5 个线程同时写日志”。信号量没有“所有权”概念，任何线程都可以释放，因此不适合“保护数据”场景，适合“限流”场景。
3. 自旋锁（spinlock）
   纯自旋，不休眠。实现简单，只需一个整型变量+CAS 指令。优点：没有上下文切换，适合“临界区极短”且“线程数≤CPU 核数”的场合；缺点：CPU 空转，容易把核心跑满。实时系统里常用“带退避的自旋锁”：失败次数越多，下次自旋前睡眠越久，打散竞争高峰。
4. 队列锁（MCS、CLH）
   每个线程在本地变量自旋，而不是全局变量，避免“所有核都砸同一个地址”。“本地变量”可以是数组元素，也可以是链表节点。队列锁把“全局自旋”变成“局部自旋”，大幅降低缓存行争用，是 Java synchronized、C++ std::mutex 的底层常客。

四、标准库实现：std::mutex、std::recursive_mutex、std::shared_mutex 的底层面孔

1. std::mutex
   Linux 下通常封装 pthread_mutex，底层是 futex（快速用户空间互斥体）：先在用户态自旋，若获取不到，再陷入内核挂起。Windows 下封装 CriticalSection，同样是“自旋+内核事件”混合策略。标准库只暴露 lock/unlock 接口，自旋次数、退避算法由平台实现决定。
2. std::recursive_mutex
   允许同一线程多次获取。实现里多一个“获取计数器”与“所有者线程 ID”。计数大于零时，只有所有者可以再次加锁，其余线程排队。递归锁容易掩盖“函数重复调用”的设计缺陷，官方文档也不推荐使用，底层实现却比 mutex 更复杂，因为需要“原子地”更新计数器与所有者。
3. std::shared_mutex（读写锁）
   允许多个读者或一个写者。常见实现是“32 位整数拆两段”：高 24 位存读者数，低 8 位存写者标记。获取读锁时，高 24 位原子递增；获取写锁时，先 CAS 把低 8 位写标记置 1，再把高 24 位清零。读锁之间无竞争，写锁到来时“阻塞新读者、等待旧读者”，实现复杂，但“读多写少”场景性能突出。
4. 自旋锁的封装：std::atomic_flag
   标准库里最简自旋锁，底层就是一个原子布尔。由于必须“忙等”，不适合长临界区，常被用作“短生命周期标志位”，例如“是否正在初始化”“是否正在关闭”。

五、内存序：lock() 与 unlock() 隐含了什么屏障

1. lock() 隐含“获取”屏障
   保证“临界区内的读写”不会被重排到“加锁”之前；其他线程看到的是“先加锁，再访问数据”。
2. unlock() 隐含“释放”屏障
   保证“临界区内的读写”不会被重排到“解锁”之后；其他线程看到的是“数据写完，再解锁”。
3. 与 volatile 的区别
   volatile 只保证“可见性”与“顺序性”，不保证“原子性”；mutex 既保证原子性，又通过屏障提供顺序性。换句话说，volatile 是“提醒大家去看黑板”，mutex 是“一次只允许一个人上台写黑板”。
4. 与原子变量的联动
   若临界区很短，可以“原子变量+内存序”代替 mutex；若临界区涉及多条语句或外部调用，仍推荐 mutex。面试常问“什么时候用原子变量替代锁？”答案就是：当操作可以“单行完成”且“竞争不激烈”时。

六、用户态自旋 vs 内核态挂起：一条分界线的两端

1. 自旋阶段
   线程在用户态循环 CAS，CPU 利用率 100%，但无需系统调用，延迟低；适合“临界区小于上下文切换时间”的场景。
2. 挂起阶段
   自旋失败达到阈值后，线程陷入内核，加入等待队列，CPU 立即调度其他任务；锁释放时，内核按“公平策略”或“唤醒风暴”方式唤醒等待者。挂起后 CPU 利用率下降，但带来上下文切换开销。
3. 混合策略
   现代 mutex 都采用“自旋+挂起”混合：先自旋若干次，再挂起；自旋次数可自适应——如果历史数据显示“锁常很快释放”，就增加自旋上限，否则减少。自适应算法让 mutex 在“低延迟”与“节能”之间动态权衡。

七、原子变量：CAS 的“官方封装”

1. std::atomic
   提供 load、store、exchange、compare_exchange 等操作。compare_exchange 即“CAS”语义，成功返回 true，失败返回 false。用户可指定内存序：relaxed、acquire、release、acq_rel、seq_cst。不同内存序影响编译器和 CPU 的重排程度。
2. 无锁队列
   用 atomic<Node*> 实现链表，通过 CAS 把新节点插入头/尾。ABA 问题用“tagged pointer”或“原子引用+版本号”解决。无锁队列在高并发、低延迟系统里广泛使用，但实现复杂度远高于“加锁队列”。
3. 与 mutex 的取舍
   无锁算法性能高，但调试困难、可读性差、对内存序要求苛刻；mutex 实现简单、可读性好、可调试。一般原则：核心路径、竞争极高、延迟敏感才用无锁；业务逻辑、长临界区、可读性优先用 mutex。

八、性能陷阱：你以为 lock() 很快，其实 CPU 在狂奔

1. 临界区长
   里面睡了一秒，外面 100 个线程一起自旋，CPU 瞬间跑满 100%，系统负载飙到 100+，但用户态没做任何有用工作。
2. 伪共享
   锁变量与业务数据在同一缓存行，线程 A 只改业务数据，线程 B 只抢锁，却导致缓存行来回失效，性能掉一个数量级。
3. 唤醒风暴
   锁释放瞬间，内核唤醒所有等待线程，这些线程又一起抢锁，最终只有一个成功，其余再次睡眠，造成“上下文切换雪崩”。
4. 公平性
   某些实现为了吞吐量采用“非公平”策略，允许新来线程直接抢锁，旧线程长时间饥饿；实时系统里要选用“公平锁”或“队列锁”，保证先来先服务。

九、调试与观测：如何让“隐形锁”现形

1. 系统级
   Linux 的 perf lock 可记录 lock 事件、持有时间、等待时间；Windows 的 ETW 也能追踪 CriticalSection 争用。
2. 应用级
   在 lock() 前后埋点，记录“线程 ID、时间戳、锁名称、事件类型（抢锁/释放）”，输出到日志或 JFR，再用可视化工具分析热点锁。
3. 死锁检测
   对每把锁分配全局序号，抢锁时必须按序号升序；若检测到“降序”抢锁，立即报错。此法可提前发现“环形等待”。

十、高级话题：读写锁、自旋锁、队列锁、原子变量混合实战

1. 读写锁 + 原子计数
   用原子变量记录“当前读者数”，写锁到来时CAS置标记，读者释放完最后一个计数后唤醒写者；兼顾“读并发”与“写排他”。
2. 队列锁 + 自旋
   MCS 锁每个线程本地自旋，减少缓存行争用；若临界区极短，可在队列节点里再嵌套几圈自旋，减少“陷入内核”次数。
3. 原子变量 + 版本号
   无锁链表插入时，CAS 比较“指针+版本号”，解决 ABA；版本号放在指针高位，利用 64 位地址对齐特性，不额外占用内存。