自旋锁与互斥锁：锁持有时间影响性能开销

本文深入剖析了自旋锁与互斥锁在Linux内核中的本质差异与适用边界，指出锁的选择绝非简单比较“快慢”，而应基于临界区实际执行时间、是否允许睡眠、上下文类型及资源竞争模式进行精准权衡：自旋锁仅在纳秒级、纯CPU计算且中断/抢占已禁用的原子场景中高效，滥用会导致CPU空转和系统拖慢；互斥锁虽引入调度开销，却在毫秒级、含内存分配或I/O的常规路径中更安全可靠；而真正提升性能的关键，在于跳出锁类型之争，通过实测分析临界区耗时与竞争热度，并善用rwsem、RCU、per-CPU变量等更契合数据访问模式的无锁或低开销机制——最终，优化锁的本质，是优化被锁住的代码本身。

自旋锁适合什么场景？spin_lock 不是“更快”的代名词

自旋锁只在锁持有时间极短（通常 while (!try_acquire()) { cpu_relax(); }，CPU 一直跑空循环，不交出调度权。

常见错误现象：在可能触发页缺失、系统调用或内存分配的临界区里用 spin_lock —— 这会导致 CPU 白白烧着，还拖慢其他核上的任务。

• 适用场景：中断上下文、内核中已禁用抢占的原子路径、纯 CPU 计算型临界区（如更新一个计数器）
• 不适用场景：任何可能调用 kmalloc(GFP_KERNEL)、访问用户内存、等待 I/O 或调用 schedule() 的地方
• 参数差异：spin_lock(&lock) 会禁用本地中断（防止中断 handler 抢占并死锁），而 spin_lock_bh() 只禁用 softirq/bh，选错会引发隐性竞态

互斥锁为什么默认更安全？mutex_lock 的代价藏在哪

mutex_lock 是睡眠锁，拿不到就主动让出 CPU，调度器换别的线程跑。这避免了 CPU 浪费，但引入了上下文切换开销和调度延迟。

容易踩的坑：在中断上下文或禁止睡眠的区域（比如 atomic 上下文、RCU read-side）调用 mutex_lock，会直接触发 BUG: scheduling while atomic 错误。

• 适用场景：进程上下文、临界区可能较长（微秒到毫秒级）、需要做内存分配或文件 I/O 的逻辑
• 性能影响：单次 mutex_lock 在无竞争时约 20–50 纳秒；有竞争时，一次唤醒+调度可能耗时几十微秒甚至更多
• 注意 mutex_trylock()：它不睡眠，但失败后你得自己处理重试或降级逻辑，别当成 spin_trylock() 的平替

别硬选 —— Linux 内核里怎么动态切换？rwsem 和 rcu_read_lock 是替代选项

当读多写少，或者临界区语义允许延迟可见，硬套 spin_lock 或 mutex_lock 都是过杀。这时候得看数据访问模式，而不是只盯“锁快不快”。

典型误判：为保护一个被频繁读取的配置结构体，用 spin_lock —— 实际上 struct rw_semaphore 的读端几乎无开销，写端才阻塞，整体吞吐反而更高。

• rwsem：读并发安全，写独占；比 mutex 多一点元数据，但读路径不进内核调度器
• rcu_read_lock()：零锁开销，但要求写端用 call_rcu() 延迟释放旧数据，适用于指针替换类操作（如路由表、模块列表）
• 混合策略：小粒度用 spin_lock，大块逻辑外包给 mutex，中间状态用 atomic_t 或 lockless ringbuffer

实测前先问自己三个问题

很多开销争议其实源于没看清真实瓶颈。不是锁类型决定性能，而是锁保护的那段代码本身是否合理。

• 这段临界区平均执行多久？用 kprobe + perf record -e sched:sched_stat_sleep,sched:sched_stat_runtime 看实际阻塞/运行时间分布
• 锁竞争频率高吗？/proc/lock_stat（需开启 CONFIG_LOCK_STAT）能暴露 spin_lock 的等待次数和总纳秒数
• 有没有办法把锁粒度变细、挪出慢路径、或用 per-CPU 变量避开争抢？例如把全局计数器换成 struct this_cpu_counter

真正难的从来不是选 spin_lock 还是 mutex_lock，而是确认你锁住的那几行代码，是不是真的需要被锁住。

理论要掌握，实操不能落！以上关于《自旋锁与互斥锁：锁持有时间影响性能开销》的详细介绍，大家都掌握了吧！如果想要继续提升自己的能力，那么就来关注golang学习网公众号吧！