C++如何使用std::atomic::compare_exchange_weak构建非阻塞互斥锁

compare_exchange_weak 为什么适合做自旋锁

compare_exchange_weak 之所以适合做自旋锁，关键在于它的失败开销更低。在 x86 这类架构上，伪失败不会触发内存屏障或总线锁，对缓存行压力更小；同时它返回 bool 并更新 expected 值，恰好匹配“读-改-写-重试”的逻辑。当然，使用时必须用循环重试，并且每次都要重置 expected 为 false。

weak 版本的优势在哪里？其实就一句话：它的失败开销比 compare_exchange_strong 更低。在某些架构（比如 x86）上，compare_exchange_weak 可能会因为伪失败而重试，但注意——它不会触发内存屏障或总线锁，对缓存行的压力小得多。而自旋锁本身就是预期短时间竞争的场景，用 weak 版本自然更高效。

关键点在于它返回 bool 表示 CAS 是否成功，并通过引用参数更新期望值——这恰好匹配“读-改-写-重试”的自旋逻辑。使用时有几个硬性要求：

• 必须用循环包裹，因为 weak 可能假失败
• 不能依赖单次调用结果，要检查返回值并更新 expected
• 初始 expected 必须设为 false（未加锁状态），锁变量本身用 std::atomic

一个最小可行的 spinlock 实现

只用 std::atomic 和 compare_exchange_weak 就能写出可工作的非阻塞锁：

struct spinlock {    std::atomic locked_{false};    void lock() {        bool expected = false;        while (!locked_.compare_exchange_weak(expected, true)) {            expected = false; // 重置期望值，应对伪失败        }    }    void unlock() {        locked_.store(false, std::memory_order_release);    }};

注意两点：

• lock() 中每次循环都重置 expected = false，否则伪失败后 expected 可能残留为 true，导致后续 CAS 永远失败
• unlock() 用 std::memory_order_release 即可，配合 lock() 中默认的 std::memory_order_seq_cst（或显式用 acquire）构成 acquire-release 同步

实际使用时容易卡死的三个坑

看似简单，但掉进下面任一坑都会让线程永久自旋：

• 忘记在循环内重置 expected → 伪失败后 expected 保持 true，CAS 总是拿 true 去比 false，永远失败
• 在 lock() 中用了 std::memory_order_relaxed → 缺少 acquire 语义，编译器/CPU 可能把临界区代码重排到锁外
• 持有锁期间调用可能阻塞的操作（如 std::cout <<、系统调用）→ 自旋锁必须极短，否则浪费 CPU 且破坏公平性

尤其注意：C++ 标准不保证 std::atomic::compare_exchange_weak 在所有平台都真正“weak”，但行为一致——你仍得按 weak 的语义写循环，不能偷懒只试一次。

和 std::mutex 相比，什么场景才该用它

不是为了“更高级”，而是为特定低延迟、无内存分配、确定性调度的场景：

• 实时线程中禁止进入内核态（比如硬实时音频处理）
• 锁保护的临界区平均耗时 < 几百纳秒
• 嵌入式环境没有完整 libc 或线程栈受限，无法承受 mutex 的内部 malloc 或 futex 等开销

一旦临界区变长或竞争变激烈，自旋会吃光 CPU，此时 std::mutex 的休眠机制反而更优。别为了“无锁”而无锁——spinlock 仍是锁，只是不交出 CPU。