10、自旋锁：自旋锁的原理、自旋锁与互斥锁的选择、自旋锁的实现

自旋锁，这个名字听起来有点玄乎。说白了，它就是一把「死等」的锁。

你想想看，互斥锁是线程拿不到锁就睡觉，等锁释放了再被叫醒。自旋锁不一样——它拿不到锁就原地转圈，不停地问「锁好了没？锁好了没？」直到拿到为止。

我刚开始接触并发编程时，觉得自旋锁这玩意儿太傻了。CPU 空转，多浪费啊。后来在项目中踩过坑，才明白它存在的意义。

自旋锁的原理

自旋锁的实现基础，是 CPU 提供的原子操作指令。比如 x86 上的 lock cmpxchg，ARM 上的 LDREX/STREX 对。

它的工作流程很简单：

1. 线程 A 尝试原子地修改锁变量（从 0 改成 1）
2. 如果成功，线程 A 进入临界区
3. 如果失败（锁已经是 1），线程 A 不断重试步骤 1
4. 线程 B 释放锁时，把锁变量改回 0
5. 线程 A 在下一次重试时成功获取锁

嗯，这里要注意。自旋锁必须保证「检查-设置」这两个操作是原子的。否则两个线程同时看到锁是 0，同时设置成 1，那就乱套了。

我在项目中遇到过一个问题：一个同事自己手写了个自旋锁，用了 if(lock==0) lock=1; 这种非原子操作。结果线上服务偶尔出现两个线程同时进入临界区，数据全乱了。排查了两天才找到原因。

自旋锁 vs 互斥锁：怎么选？

这个问题，我经常被问到。其实没有绝对的好坏，关键看场景。

对比维度	自旋锁	互斥锁
等待方式	忙等待（CPU 空转）	阻塞等待（线程休眠）
上下文切换	无	有（开销较大）
适用场景	临界区极小，锁持有时间短	临界区较大，锁持有时间长
CPU 占用	等待时持续占用 CPU	等待时不占用 CPU
实时性	响应快（无调度延迟）	有调度延迟

我个人习惯这样判断：如果临界区的执行时间小于两次上下文切换的开销，就用自旋锁。否则用互斥锁。

举个例子。你在操作一个链表头指针，只是改个指针指向，几纳秒的事。这时候用互斥锁，线程切进切出，反而更慢。

但如果你要在临界区里写文件、做网络请求，那千万别用自旋锁。我曾经见过一个项目，有人在数据库查询操作外面套了自旋锁，结果高并发时 CPU 直接飙到 100%，所有线程都在空转等锁。

自旋锁的实现

我们来看一个简单的自旋锁实现。用 C11 的原子操作：

#include <stdatomic.h>

typedef struct {
    atomic_int flag;
} spinlock_t;

void spinlock_init(spinlock_t *lock) {
    atomic_store(&lock->flag, 0);
}

void spinlock_lock(spinlock_t *lock) {
    // 不断尝试将 flag 从 0 改成 1
    while (atomic_exchange(&lock->flag, 1) != 0) {
        // 可以在这里加 CPU pause 指令，减少功耗
        // 在 x86 上：__asm__ volatile ("pause");
    }
}

void spinlock_unlock(spinlock_t *lock) {
    atomic_store(&lock->flag, 0);
}

这个实现够用，但有个问题：所有等待的线程都在激烈竞争同一个变量，导致缓存一致性流量很大。这叫「惊群效应」。

改进一下，用「测试-测试-设置」（TTAS）策略：

void spinlock_lock_tas(spinlock_t *lock) {
    // 先读一下，如果锁被占用，就不发原子操作
    while (atomic_load(&lock->flag) != 0) {
        // 空转等待
    }
    // 锁看起来空闲了，再尝试原子获取
    while (atomic_exchange(&lock->flag, 1) != 0) {
        // 如果获取失败，继续等待
    }
}

等等，上面这个代码有个竞态条件。两个线程可能同时看到 flag 为 0，然后都去执行 atomic_exchange。不过没关系，atomic_exchange 是原子的，最终只有一个能成功。

更好的写法是这样：

void spinlock_lock_ttas(spinlock_t *lock) {
    while (1) {
        // 先读，不修改缓存
        while (atomic_load(&lock->flag) != 0) {
            // 自旋等待，只读不写
            __asm__ volatile ("pause");
        }
        // 只有看到锁空闲时，才尝试获取
        if (atomic_exchange(&lock->flag, 1) == 0) {
            break;
        }
    }
}

自旋锁的变种

实际工程中，我们很少用朴素的自旋锁。有几个常见的改进版本：

• 票证自旋锁（Ticket Spinlock）：每个等待线程拿一个号码，按顺序获取锁。避免了惊群效应。
• MCS 锁：每个线程在自己的本地变量上自旋，减少了缓存一致性流量。
• 读写自旋锁：允许多个读者同时访问，写者独占。

我记得在优化一个消息中间件时，把朴素的原子自旋锁换成了 MCS 锁，在高并发场景下吞吐量提升了 15%。原因就是 MCS 锁让每个线程只在自己的缓存行上自旋，不再互相干扰。

自旋锁的使用原则

最后，总结几条我这些年攒下来的经验：

1. 临界区要短。超过几百条指令就别用自旋锁了。
2. 不要在自旋锁内调用可能阻塞的函数。比如 malloc、printf、系统调用。否则整个系统可能死锁。
3. 考虑优先级反转。如果低优先级线程持有自旋锁，高优先级线程在等锁，低优先级线程可能被调度出去，导致高优先级线程空转。
4. 多核系统上才用自旋锁。单核系统用自旋锁等于自杀。
5. 能不用就不用。能用无锁数据结构，就别用锁。能用互斥锁，就别用自旋锁。

自旋锁就像一把双刃剑。用好了，它是高性能的利器。用不好，它就是 CPU 资源的黑洞。嗯，希望你能在实际项目中找到那个平衡点。