互斥与同步原语

可视化演示

展示自旋锁与互斥锁、信号量P/V、原子操作CAS与死锁预防。

临界区与竞态

切菜台是整个后厨最紧张的地方，因为所有人共用一张台面。如果两位厨师同时把手伸向同一摞盘子，轻则菜撒一地，重则盘子摔碎。计算机世界里，这段“同一时刻只允许一个线程进入”的代码区域，就叫临界区（Critical Section）。而多个线程同时读写共享数据、导致结果不可预测的现象，叫做竞态条件（Race Condition）。

为什么一行代码就能引发混乱？因为高级语言里的 counter++，在 CPU 眼中其实是三步动作：先从内存读出值，在寄存器里加一，再写回内存。A 线程读到 50，还没写回，B 线程也读到 50，两个线程都把 51 写回——本该加两次变成 52，结果只有 51。这就是“丢了更新”。

这三步必须“一气呵成”，中间不能被别的线程打断。这种不可分割的性质就叫原子性（Atomicity）。厨房的解决办法简单粗暴：在切菜台放一块牌子，谁拿到牌子谁进去，出来再把牌子挂回去。计算机里的这块牌子，就是互斥锁。

互斥锁机制

上节说到的“牌子”，就是互斥锁（Mutex）。但牌子也分性格。自旋锁（Spinlock）像守在门口干等的厨师——进不去就在门口来回踱步，CPU 被白白耗着。互斥锁则像先去备菜、等喊号再回来的厨师——进不去就挂起线程，把 CPU 让给别的任务。两者各有适用场景：临界区极短、CPU 核多，自旋更划算；临界区长、并发量大，互斥锁更省资源。

现代语言里到处是这块牌子：Python 的 threading.Lock、Java 的 synchronized 和 ReentrantLock、Go 的 sync.Mutex。选锁时还要考虑公平性：先到的厨师先拿到牌子，还是可能被后来的插队？公平锁能避免“饿死”，但会牺牲一点吞吐。

信号量机制

烤箱只有一个要守门，灶台却有六个。如果给每个灶台单独挂锁，厨师们来回跑腿累得够呛。不如在门口挂一块“余位牌”：写着剩余可用灶台数，每次进去一个人数字就减一，出来再加一。这个“余位牌”就是信号量（Semaphore），由计算机科学家 Dijkstra 提出，配套两个原语：P（Proberen，荷兰语“测试”）和 V（Verhogen，“增加”）。

信号量的计数值为 1 时退化为二值信号量，但它和互斥锁有个微妙差异：互斥锁讲究“谁持有谁释放”，信号量却允许别的线程代为 V 操作。这既是灵活性，也是容易踩坑的地方。

条件变量

厨师把蛋糕放进烤箱后，总不能搬把椅子守在烤箱前干瞪眼。后厨的做法是：烤箱装上铃铛，烤好了“叮”一声。厨师可以去休息室眯一会儿，听到铃声再起来干活。这个“铃铛”就是条件变量（Condition Variable）。它必须配合互斥锁使用：线程发现条件不满足时，释放锁并进入休眠；条件满足时，别的线程发信号唤醒它。

实际编程中要警惕虚假唤醒（Spurious Wakeup）：被唤醒不一定代表条件真的成熟了。所以要用 while 循环重新检查条件，就像厨师被喊醒后先揉揉眼确认——哎，是隔壁的人在喊自己的亲戚，那接着睡。

读写锁

餐厅里，菜单是公开的，所有客人同时看都没问题（读）；但改菜单的主厨只有一个（写）。如果每次修改菜单都用一把互斥锁把整本菜单锁死，想看菜单的客人也得排队，那生意就没法做了。读写锁正是为此设计：读锁可以多线程同时持有，写锁必须独占。核心规则是：读读并发、读写互斥、写写互斥。

读写锁有两种调度策略：读者优先下，只要一直有读者来，写者可能被活活饿死；写者优先则让新读者在写者到达后暂停入场，避免写者饥饿。多数数据库系统采用写者优先或“先到先得”的公平策略。

死锁与饥饿

两位厨师，A 握着炒锅要等 B 手里的锅盖，B 握着锅盖要等 A 手里的炒锅。谁也不肯先松手，后厨彻底僵住——这就是死锁（Deadlock）。死锁的发生需要四个条件同时满足：互斥（资源一次只能一人用）、持有并等待（拿着资源还要等别的）、不可剥夺（不能强行抢）、循环等待（A 等 B、B 等 A 形成环）。

应对死锁有三种思路：预防（破坏四个条件之一，比如规定所有厨师必须按“先锅后盖”的顺序拿工具）、避免（银行家算法，动态判断这次分配是否安全）、检测与恢复（用工具检测等待环，强制打断）。此外还有饥饿：不是死锁，但某些线程一直抢不到资源，像总排不到灶台的学徒——没被卡死，却活不下去。

锁性能调优

餐厅客流越大，锁的粒度问题越突出。粗粒度锁：整个厨房只挂一块牌子，谁进去谁全包，实现简单但效率极低——一个人炒菜，全员围观。细粒度锁：每个台面独立挂牌，不同厨师可同时在各区域干活，并发度高但管理复杂——每个牌子都要防抢、防错、防死锁。

调优手段还有：分段锁（把一个大烤箱拆成多个小烤箱，如 ConcurrentHashMap 的分段设计）、读写锁替换互斥锁、无锁数据结构（用 CAS 实现）。评估指标看两个：吞吐量（单位时间出多少菜）和延迟（一道菜从下单到上桌多久）。

内存与原子

切菜最怕切到一半接电话。有没有一种“一刀到底”的操作？CAS（Compare-And-Swap，比较并交换）就是硬件提供的一条原子指令：先比较内存中的值是否等于期望值，如果等于，就换成新值。整个操作只花一条指令的时间，谁都打断不了。

CAS 有著名的 ABA 问题：值从 A 变成 B 又变回 A，CAS 会误以为“没人动过”。解法是带上版本号（如 Java 的 AtomicStampedReference）。还有内存模型问题：各 CPU 核心有本地高速缓存，线程 A 修改了变量，线程 B 的缓存里可能还是旧值。原子变量和内存屏障（Memory Barrier）就是强制“把誊写结果同步给大家看”的规矩。

AI 应用场景

Python 演示

import threading counter = 0lock = threading.Lock()N = 1000T = 4  def increment_locked():    global counter    for _ in range(N):        with lock:            counter += 1  def increment_unlocked():    global counter    for _ in range(N):        counter += 1  def run(fn, label):    global counter    counter = 0    threads = [threading.Thread(target=fn) for _ in range(T)]    for t in threads:        t.start()    for t in threads:        t.join()    print(label, counter, "expected", T * N)  def main():    run(increment_unlocked, "no-lock:")    run(increment_locked, "locked: ")  if __name__ == "__main__":    main()

1. counter = 0共享变量，就像那块所有人都要用的切菜台，是竞态发生的现场。
2. with lock:获取互斥锁（拿牌子），离开缩进自动释放（挂回牌子），是保护临界区的关键一行。
3. counter += 1一行代码在字节码层面是“读→加→写”三步，正是竞态窗口所在。
4. threading.Thread(target=fn)创建厨师线程，每个线程独立执行 fn 函数。
5. t.start()` / `t.join()前者让厨师开工，后者等厨师干完活再收工，保证主线程最后打印的是全部线程完成后的结果。

常见误区

面试题