C++ atomic_flag实现自旋锁 _ 无锁同步机制入门【干货】

C++ atomic_flag实现自旋锁 | 无锁同步机制入门【干货】

atomic_flag 为什么不能直接用 operator== 判断状态

这事儿得从设计初衷说起。atomic_flag 被刻意设计成“只写不可读”的原子类型——它既不提供 load() 方法，也不允许隐式转换成 bool。为什么这么“不近人情”？目的很明确：就是为了强制开发者必须通过“测试并置位”（test_and_set()）这个原子操作来建模自旋逻辑。很多新手会下意识地写 if (flag == false)，结果编译直接报错。这可不是语言在刁难你，而是在善意提醒：别试图绕过原子语义，那会引入数据竞争。

正确的打开方式只有一种：依赖 test_and_set() 的返回值，它返回的是操作前的旧值，并且默认使用最强的顺序一致性内存序（memory_order_seq_cst）：

std::atomic_flag flag = ATOMIC_FLAG_INIT;
// 想知道锁是否空闲？只能靠“试”：
while (flag.test_and_set(std::memory_order_acquire)) {
    // 在这里自旋等待，或者考虑加入适度的退让策略
}

• 初始化必须使用宏 ATOMIC_FLAG_INIT。如果尝试用空的花括号 {} 或 = {}，尤其在静态存储期对象上，可能导致未定义行为。
• test_and_set() 这个操作有个固定动作：总是把标志设为 true。它返回的是“设置之前”的值。所以，如果第一次调用返回 false，恭喜你，抢锁成功。
• 自旋循环里要慎用 std::this_thread::yield()。它并不保证会让出CPU，在某些平台上可能等同于空转。真想降低CPU占用，可以考虑短暂的休眠或指数退避策略。

自旋锁构造函数里忘记 clear() 会导致首次 lock() 永远阻塞

这是一个经典的坑。新创建的 atomic_flag 对象，其初始状态是“未指定的”（unspecified），而不是自动为 false。如果你跳过了初始化步骤，那么第一次调用 test_and_set() 就有可能返回 true，导致锁永远无法获取。

安全的构造函数写法主要有两种：

立即学习“C++免费学习笔记（深入）”；

struct spinlock {
    std::atomic_flag flag;
    spinlock() : flag(ATOMIC_FLAG_INIT) {} // ✅ 推荐：在成员初始化列表里完成
    // 或者另一种写法：
    // spinlock() { flag.clear(std::memory_order_relaxed); }
};

• clear() 是唯一能将 atomic_flag 设为 false 的方法，必须显式调用。ATOMIC_FLAG_INIT 这个宏，展开后本质上就是提供了 ATOMIC_VAR_INIT(false) 级别的初始化保障。
• 注意，不要在类内直接写 std::atomic_flag flag{ATOMIC_FLAG_INIT}。C++11 不支持非静态数据成员的花括号初始化（C++14 起允许，但仍需注意ABI兼容性风险）。
• 如果锁需要重复使用（即 unlock 之后再次 lock），那么每次 unlock 时都必须调用 flag.clear(std::memory_order_release)，否则下一次 lock 必然失败。

memory_order 选错会让自旋锁在多核上失效

自旋锁的目标远不止“避免线程阻塞”那么简单，它的核心使命是保证临界区内的内存访问顺序不被编译器和处理器重排，同时确保缓存一致性。一个最常见的错误就是全部使用最宽松的 memory_order_relaxed：

// ❌ 危险操作：临界区内的读写可能被重排到 lock() 之前，或拖到 unlock() 之后
while (flag.test_and_set(std::memory_order_relaxed)) {}
// ... 临界区代码 ...
flag.clear(std::memory_order_relaxed);

正确的内存序组合应该是：

• test_and_set(std::memory_order_acquire)：这是一个“获取”操作，确保该操作之后的所有读写都不会被重排到它前面去。
• clear(std::memory_order_release)：这是一个“释放”操作，确保该操作之前的所有读写都不会被重排到它后面去。
• 这一对“获取-释放”操作共同构成了一个同步点，使得不同线程能观察到一致的修改顺序。

从性能角度看，acquire/release 在 x86/x64 架构上几乎没有额外开销（依赖硬件内存屏障）。但在 ARM/AArch64 架构上，它们会生成类似 dmb ish 的指令——这笔开销绝对不能省，这是正确性的代价。

为什么不用 atomic_bool 替代 atomic_flag 实现自旋锁

当然可以这么做，但通常不建议，因为它容易引入一些隐蔽的bug。有人为了图方便会写成这样：

std::atomic flag{false};
while (flag.exchange(true, std::memory_order_acquire)) {} // ❌ 潜在问题！

这里存在几个关键差异：

• exchange() 是一个“读-改-写”操作，而 atomic_flag::test_and_set() 通常对应更底层的原子指令（在 x86 上可能是 XCHG 或 LOCK BTS）。
• 更重要的是语义保证：atomic_flag 标准要求在所有平台上都必须是“无锁”（lock-free）实现的，绝不会在底层偷偷使用互斥量。而 atomic 在某些特定平台（例如一些旧的 ARMv7 实现）上，有可能退回到基于互斥锁的实现，那这就不是真正的“自旋”锁了。
• atomic_flag 通常也更轻量，没有额外的填充字节和对齐冗余，sizeof(std::atomic_flag) 往往是 1 个字节。

如果确实想用 atomic，务必先调用 is_lock_free() 确认其底层实现。并且，exchange 操作的内存序参数需要仔细配对（例如 acquire 配对 release），不能只用一个内存序了事。

说到底，实现一个自旋锁的代码不过四五行，真正的难点在于理解 test_and_set() 返回值与内存序之间那份脆弱的契约。漏掉其中任何一环，程序可能在99%的机器上运行无误，却在剩下的1%场景下出现死锁或静默的数据错误。这才是最需要警惕的地方。