减少无脑自旋：用 C++20 std::atomic::wait 提升自旋锁的唤醒效率与功耗表现

在多线程高并发场景下，自旋锁（Spinlock）因其“无内核态切换”、“极端低延迟”的特性，常常被用作保护临界区的首选武器。然而，传统的自旋锁存在一个致命的硬伤：忙等（Busy-waiting）。

当锁的持有时间变长，或者线程竞争激烈时，处于等待状态的 CPU 核心会执行无意义的循环，导致 CPU 使用率飙升到 100%，整机功耗大增，甚至引发缓存一致性风暴。

C++20 引入的 std::atomic::wait 和 std::atomic::notify_one / notify_all 为我们提供了一种优雅的解决方案。在 Linux 平台上，这一机制在底层直接映射为 futex（Fast Userspace Mutex）系统调用。

本文将探讨如何利用 C++20 的新特性，实现一个既保留自旋锁低延迟优势，又具备类似互斥锁（Mutex）低功耗特性的自适应自旋锁。

传统自旋锁的“痛点”与缓存风暴

最简单的自旋锁通常使用 std::atomic_flag 或 std::atomic<bool> 的 TAS（Test-and-Set）操作来实现：

class SimpleSpinLock {
    std::atomic<bool> flag{false};
public:
    void lock() {
        while (flag.exchange(true, std::memory_order_acquire)) {
            // 忙等
        }
    }
    void unlock() {
        flag.store(false, std::memory_order_release);
    }
};

这种实现存在以下几个严重问题：

1. CPU 功耗暴增：等待线程在没有拿到锁之前，会以极高频率执行 exchange 操作。
2. 缓存一致性风暴（Cache Coherency Storm）：exchange 是写操作。根据多核 CPU 的 MESI 缓存一致性协议，任何一个核心写入共享变量，都会强制使其他所有核心的 L1/L2 Cache 中的该行数据失效。多核同时自旋时，总线会被大量的缓存同步流量塞满。
3. 退化改进局限：即便我们在循环中加入汇编指令 pause（如 GCC 的 __builtin_ia32_pause()）来缓解流水线乱序执行和功耗，但在锁被长期持有的情况下，CPU 依然在空转。

C++20 std::atomic::wait 的救场

C++20 的 std::atomic::wait 改变了游戏规则。它的行为机制如下：

• atomic::wait(old_val)：首先比较当前原子变量的值是否等于 old_val。
  • 如果不相等，立即返回（说明值已经变了，不需要等待）。
  • 如果相等，当前线程将被挂起，进入阻塞/休眠状态，直到其他线程调用 notify_one() 或 notify_all()。
• atomic::notify_one()：唤醒至少一个在该原子变量上等待的线程。

它的核心优势在于：在无竞争或极短延迟时自旋；在长等待时休眠，交出 CPU 控制权。

在 Linux 平台上的底层：Futex 映射

在 Linux 平台上，libstdc++（GCC）和 libc++（Clang）对 std::atomic::wait 的实现并没有采用复杂的应用层轮询，而是直接映射到了 futex 系统调用。

当我们调用 flag.wait(true) 时，底层最终会执行类似如下的系统调用：

syscall(SYS_futex, &flag, FUTEX_WAIT_PRIVATE, true, nullptr, nullptr, 0);

• 用户态快速通道：如果锁的状态符合预期，直接在用户态完成逻辑，无需陷入内核。
• 内核态慢速通道：如果锁的状态不符合，线程在内核中挂起，由内核的等待队列接管，不再消耗任何 CPU 资源。
• 当调用 flag.notify_one() 时，底层会调用 FUTEX_WAKE_PRIVATE 唤醒排队线程。

实战：构建一个自适应混合自旋锁

为了将自旋的“低延迟”与 Futex 的“低功耗”完美结合，我们需要设计一个自适应混合自旋锁（Hybrid Spinlock）。

其策略是：先自旋固定的次数（或一段时间），如果依然无法获取锁，再退化为 atomic::wait 休眠。

#include <atomic>
#include <thread>

class AdaptiveSpinLock {
private:
    // false: 未上锁, true: 已上锁
    std::atomic<bool> state_{false};

    // 自旋限制次数，可根据具体业务场景微调
    static constexpr int SPIN_LIMIT = 100;

public:
    void lock() noexcept {
        // 1. 第一阶段：快速自旋（轻量级尝试）
        for (int i = 0; i < SPIN_LIMIT; ++i) {
            // 尝试将 false 改为 true
            if (!state_.exchange(true, std::memory_order_acquire)) {
                return; // 抢锁成功，直接返回
            }
            
            // 提示 CPU 正在自旋，优化指令流水线，降低部分功耗
#if defined(__x86_64__) || defined(_M_X64)
            __builtin_ia32_pause();
#elif defined(__ARM_ARCH) || defined(__aarch64__)
            asm volatile("yield" ::: "memory");
#endif
        }

        // 2. 第二阶段：退化为基于 Futex 的等待，防止跑满 CPU
        // 如果 exchange 返回 true（表示仍被别人占用），则进入 wait
        while (state_.exchange(true, std::memory_order_acquire)) {
            // 等待状态变为 true 以外的值（即变为 false）
            // 只要 state_ 还是 true，当前线程就会在内核中休眠
            state_.wait(true, std::memory_order_relaxed);
        }
    }

    bool try_lock() noexcept {
        return !state_.exchange(true, std::memory_order_acquire);
    }

    void unlock() noexcept {
        // 释放锁
        state_.store(false, std::memory_order_release);
        
        // 唤醒一个正在等待的线程
        // 注意：如果不确定是否有线程在 wait，notify 依然有微小的开销
        // 但在 Linux futex 下，无等待线程时 notify 仅仅是一次非常快速的内核探测
        state_.notify_one();
    }
};

关键细节剖析

1. 避免双重判定失效：
   在 while (state_.exchange(true, ...)) 循环中嵌套 state_.wait(true)，能够有效防止信号丢失（Lost Wakeup）。如果释放锁的动作发生在 exchange 失败和 wait 开始之前，wait(true) 会在内部检测到当前 state_ 已经变成了 false，从而不会挂起线程，直接再次进入循环抢锁。

2. 内存顺序（Memory Order）的裁量：

   • 在抢锁的 exchange 动作中，我们使用 std::memory_order_acquire，保证临界区内的读写操作不会被重排到锁获取之前。
   • 在 unlock 中，使用 std::memory_order_release，确保临界区内的数据修改在锁释放前全部对其他线程可见。
   • 在 state_.wait 中，我们只需使用 std::memory_order_relaxed，因为同步的语义已经由外层的 exchange 和 store 完美承载。

性能对比与选型建议

什么时候该用 AdaptiveSpinLock？

• 临界区执行时间极短，但竞争不确定：例如高频的哈希表槽位写入、无锁队列的备用阻塞方案。
• 延迟极其敏感，同时无法接受单核空转：这在游戏引擎的主循环物理更新、高频交易系统的网卡收包队列中非常常见。
• 跨平台开发：C++20 的这一抽象屏蔽了底层 Linux futex 和 Windows WaitOnAddress 的 API 差异，让同一份高性能代码能在不同平台编译并发挥极致性能。