Futex：Linux 的锁为什么大多数时候根本不需要进内核？

Linux 里的很多锁看起来像内核对象，实际上在没有竞争时根本不会进入内核。Futex（Fast Userspace muTEX）就是这种设计的代表：把大多数状态放在用户态原子变量里，只有线程真的需要睡眠或唤醒时，才请内核介入。

可以想象一栋办公楼的门禁。平时门是开的，员工读取一个共享状态就能直接进出；只有两个人同时到门口、需要排队时，门卫才记录等待者并安排唤醒。如果每个人每次进楼都先去门卫处登记，系统就会把大量时间浪费在上下文切换上。Futex 先走用户态快速路径，避免了这份固定成本。

一个典型互斥锁会用原子操作尝试把状态从未占用改成占用。成功时，整个加锁和解锁都可能只涉及用户空间的内存访问；失败时，线程调用 futex wait，把自己挂到内核等待队列，并在状态满足条件时睡眠。持锁线程释放锁后，如果发现有等待者，再调用 futex wake 唤醒其中一个或一批线程。

Futex 的一个重要语义是“可能伪唤醒”，所以等待者不能只睡一次，而要放在循环里反复检查条件。这种设计也避免了丢失唤醒：调用 wait 前要把期望值交给内核，只有共享变量仍等于这个值时才睡眠。用户态的原子检查和内核态的条件等待因此衔接在一起。

它并不是直接给应用提供一把完整的高级锁，而是一个低层构件。线程库用它构造互斥锁、条件变量、读写锁和信号量，并负责公平性、优先级、超时和错误处理。理解 Futex 后，就能解释为什么高性能锁在无竞争时很轻，却在竞争激烈时会突然出现调度、唤醒和上下文切换成本。

锁的公平性也不是 Futex 自动提供的。多个等待线程被唤醒后，谁先重新抢到用户态状态，取决于线程调度、优先级和实现策略；高优先级任务还可能被低优先级持锁者拖住。线程库会在自旋、排队、唤醒和让渡之间寻找平衡，应用则应尽量缩短持锁区，避免把昂贵 I/O 放进锁里。

资料来源：Linux futex(7) 手册