# 自旋锁 vs 互斥锁：自旋还是睡眠的阈值决策 > 混合锁的核心决策逻辑：低争用短临界区短暂自旋，高争用长持锁回退futex睡眠，通过perf/strace经验调优阈值。 ## 元数据 - 路径: /posts/2025/12/08/spinlocks-vs-mutexes-spin-sleep-thresholds/ - 发布时间: 2025-12-08T10:48:38+08:00 - 分类: [systems-engineering](/categories/systems-engineering/) - 站点: https://blog.hotdry.top ## 正文 在多线程并发编程中，选择自旋锁（spinlock）还是互斥锁（mutex）是优化性能的关键决策。核心原则是：临界区（CS）执行时间短且争用低时，自旋等待避免上下文切换开销；反之，睡眠让出CPU给其他线程。现代pthread_mutex已内置自适应混合策略，先短暂自旋再futex睡眠，本文聚焦决策框架、阈值调优与落地参数。 ### 自旋锁与互斥锁机制对比 自旋锁通过用户态原子操作（如C11的atomic_compare_exchange_weak或x86 LOCK CMPXCHG）实现忙等待：线程循环尝试CAS（Compare-And-Swap）抢锁，直到成功，无syscall开销（~25-50ns uncontended），但失败时100% CPU消耗，每失败一次缓存线弹跳~40-80ns。 互斥锁（pthread_mutex_lock）基于Linux futex：无争用时纯用户态原子操作；争用时futex(FUTEX_WAIT) syscall睡眠（~500ns + 3-5μs上下文切换），释放时futex(FUTEX_WAKE)唤醒。glibc实现自适应自旋：若锁持有者正运行（通过任务ID检查），短暂自旋（默认30次PAUSE循环，~几百cycles）再睡眠，避免立即切换。 证据显示，自旋锁适合CS<100ns、低争用（2-4线程）；mutex适合CS>10μs或高争用。PostgreSQL LWLock用自旋短查询，mutex长IO；Redis用自旋微秒队列。 ### 风险与极限 自旋风险：高争用下CPU浪费、优先级反转（低优先线程持锁，高优先自旋饿死）、用户态抢占（线程持锁被preempt，其他自旋100ms）。mutex风险：唤醒延迟抖动（thundering herd，多个线程竞争唤醒）。 极限：NUMA多socket下缓存远程访问放大自旋成本；实时系统用PI-mutex防反转。 ### 决策阈值与调优参数 核心阈值：预期CS持锁时间 vs 上下文切换成本（~3-5μs）。若持锁<切换成本，自旋胜出。 **可落地阈值清单：** 1. **自旋时长**：初始100-500 cycles（~50-200ns@3GHz），用rdtsc测量：`uint64_t start=rdtsc(); /*CS*/ uint64_t cycles=rdtsc()-start;`。glibc默认~30 PAUSE（x86 pause指令减缓自旋，防缓存风暴）。 2. **争用阈值**：线程数<核心数*2，低争用自旋；>8线程或>10%失败率，回退睡眠。监控futex调用：`strace -c your_app`，>百万/sec热锁需分片。 3. **自适应参数**（自定义hybrid锁）： ```c int spins = 0; while (atomic_cmpxchg(&lock, 0, 1) != 0) { if (++spins > 100) { futex_wait(&lock, 1); break; } pause(); // 或 __builtin_ia32_pause() } ``` 调优：spins=50低争用，200中争用；backoff指数退避（1<