加一把锁，最坏要穿越4次用户态-内核态边界——从glibc源码拆解std::mutex的真实代价

同一把std::mutex，同一行lock()+unlock()。无竞争时一个完整周期约 50 纳秒，有竞争时膨胀到 5-15 微秒——差了100到300倍。这个差距不是线性累积出来的。它在某个临界点突然跳变——从两条原子指令跳到两次系统调用、两次上下文切换、四次穿越用户态-内核态边界。你的代码没有变，但脚下的执行路径完全换了一条。这篇拆的是这条路径。不讲 mutex 的用法，不讲 RAII 的封装技巧，只讲一件事：一把std::mutex从 C++ 标准库出发，经过 glibc NPTL 的三态锁模型，一路走到 Linux 内核的 futex 系统调用，在无竞争和有竞争两种场景下分别付出了多少代价，这些代价的来源到底是什么。先给结论。一次lock()+unlock()的完整周期，代价分成四笔：原子指令本身的缓存行开销三态状态机切换引入的额外原子操作系统调用的边界穿越税内核等待队列和调度器带来的上下文切换无竞争时只付第一笔，25 纳秒打住。有竞争时四笔全付，总价飙到 5-15 微秒。下面逐笔拆账。前置：std::mutex 到底长什么样在讲代价之前，先把被分析的对象摊开。打开 libstdc++ 的bits/std_mutex.h，std::mutex