std::mutex高频争用必触发futex系统调用，应换为std::shared_mutex（读路径免系统调用）或std::atomic（单变量原子操作），自旋锁仅适用于短临界区且需yield避饿死。
高频锁切换触发系统调用，本质是 std::mutex 在争用时陷入内核态等待 —— 这不是“能不能避免”的问题，而是“必须换掉或绕过”的问题。
std::mutex 为什么一争用就进内核？
默认的 std::mutex 是 futex（fast userspace mutex）实现：无竞争时纯用户态原子操作；一旦发现锁已被占用，立刻调用 futex(FUTEX_WAIT) 进入休眠，触发系统调用。每秒几万次争用，就是几万次上下文切换开销。
- 典型现象：
perf record -e syscalls:sys_enter_futex显示该系统调用频次远超预期 - 适用场景：临界区较长、线程数少于 CPU 核心数、写操作占比高
- 不适用场景：高频读、短临界区（如计数器增减）、大量线程争同一把锁
用 std::shared_mutex 替代 std::mutex 的真实代价
std::shared_mutex 并非“零系统调用”，但它把读路径和写路径分开处理：读线程在无写者时完全不触发系统调用，仅靠原子 load 判断状态；写线程争用失败时才可能陷入内核。
- 必须配对使用：
std::shared_lock（读） +std::unique_lock（写），混用std::lock_guard会编译失败 - 注意构造开销：
std::shared_mutex对象比std::mutex大约多 40 字节，缓存行对齐需额外留意 - Linux 上底层仍基于 futex，但读路径规避了绝大多数系统调用 —— 实测读密集场景下
futex调用次数下降 90%+
短临界区直接上 std::atomic，别碰锁
只要操作能表达为原子读-改-写（如计数、标志位翻转、指针交换），std::atomic 就是唯一正确选择。它不涉及任何锁结构体，也不调用系统 API，指令级完成。
立即学习“C++免费学习笔记（深入）”；
- 常见误用：
std::atomic<int> counter; counter++;</int>看似简单，但 ++ 是 read-modify-write，等价于fetch_add(1, std::memory_order_seq_cst)—— 若只用于单线程可见性，可降级为std::memory_order_relaxed提升性能 - 不能替代锁的场景：需要保护多变量一致性（如同时更新
x和y），或临界区含函数调用、分支逻辑、I/O - 伪共享风险更高：多个
std::atomic变量若落在同一缓存行（64 字节），彼此修改会互相驱逐缓存 —— 建议用alignas(64)隔离
自旋锁不是银弹，慎用 this_thread::yield()
自旋锁（如基于 std::atomic_flag 的实现）确实完全规避系统调用，但代价是 CPU 空转。当临界区平均耗时超过 100ns，且线程数 ≤ CPU 核心数时，它才可能比阻塞锁更优。
- 必须加
std::this_thread::yield()：否则在单核或超线程环境下，自旋线程可能饿死持有锁的线程，导致死锁式卡顿 - 不要手动写 while 循环：C++20 的
std::atomic_flag::wait()（带 pause 指令）比裸循环更友好，但目前主流编译器支持仍有限 - 生产环境建议封装为 RAII 类型（如
spinlock_guard），避免忘记clear()导致永久死锁
真正难的是判断哪段代码该用哪种同步机制 —— 很多时候不是选错锁，而是临界区本身设计过宽：比如在锁里做日志格式化、网络序列化、或调用虚函数。这些才是系统调用泛滥的根因，比换锁更值得先砍。
