std::atomic 是最简自旋锁的底层支撑，可直接实现基础自旋锁，核心是利用 exchange(true, memory_order_acquire) 的原子性；它不依赖系统调度、避免上下文切换，适合短临界区和极短等待场景。
std::atomic 是最简自旋锁的底层支撑
直接用 std::atomic 实现基础自旋锁是可行且常见的，核心在于利用其 test_and_set()（即 exchange(true, std::memory_order_acquire)）的原子性。它不依赖操作系统调度，避免上下文切换开销，适合短临界区、高争用但等待时间极短的场景。
注意：不能用 std::atomic_flag 以外的类型做“无锁”保证——std::atomic 在所有主流平台（x86-64、ARM64）上都映射为单条 lock xchg 或 ldaxr/stlxr 指令，满足自旋锁对原子写+读-修改-写的最低要求。
常见错误是误用 load() + store() 组合替代原子交换：
bool expected = false;
while (!flag.compare_exchange_weak(expected, true, std::memory_order_acquire)) {
expected = false; // 必须重置，否则 compare_exchange_weak 可能因 ABA 失败后卡住
_mm_pause(); // 推荐：x86 上提示 CPU 当前在忙等，降低功耗和总线争用
}
memory_order 选错会导致数据竞争或性能反模式
自旋锁的内存序不是“越强越好”。关键点在于：
立即学习“C++免费学习笔记（深入）”；
- 加锁用
std::memory_order_acquire：确保后续临界区读写不会被重排到锁获取之前 - 解锁用
std::memory_order_release：确保临界区内的写操作对其他线程可见 - 绝对不要在加锁时用
relaxed—— 会导致临界区指令重排进锁外，破坏同步语义 - 也不要用
seq_cst—— 在 ARM/PowerPC 上会插入昂贵的全局内存屏障，x86 虽便宜但仍是冗余
典型错误现象：临界区内更新的 int counter 值在其他线程中“偶尔看不到”，其实是编译器或 CPU 将该写操作重排到了 unlock() 之后。
std::atomic_flag 是更轻量、更标准的起点
std::atomic_flag 是 C++ 标准唯一保证“无锁”（lock-free）的原子类型，初始化必须用 ATOMIC_FLAG_INIT（C++17 起可直接用默认构造，但需调用 .clear(std::memory_order_relaxed) 初始化）。
它只提供 test_and_set() 和 clear()，语义清晰、体积最小（通常 1 字节），比 std::atomic 更贴近硬件原语：
struct spinlock {
std::atomic_flag flag = ATOMIC_FLAG_INIT;
void lock() {
while (flag.test_and_set(std::memory_order_acquire)) {
_mm_pause();
}
}
void unlock() {
flag.clear(std::memory_order_release);
}
};
使用 std::atomic_flag 的另一个好处是：编译器能更好识别这是自旋行为，某些优化（如循环展开）会被抑制，避免生成低效代码。
真实低延迟场景下必须考虑退避与公平性缺失
纯自旋锁在高争用下会持续占用 CPU 核心，导致：其他线程饿死、温度升高、Turbo Boost 频率下降、实际延迟反而升高。这不是理论风险，而是高频交易或实时音频处理中反复验证的问题。
简单改进是加入指数退避（exponential backoff）：
- 首次失败后
_mm_pause()1 次 - 第二次失败后
_mm_pause()2 次 - 最多叠加到 64 次后，改用
std::this_thread::yield()让出时间片
但要注意：yield() 会引入调度延迟（微秒级），破坏“低延迟”前提；而完全不退避又可能让锁持有者无法及时被调度（尤其在负载饱和时）。这个权衡没有银弹，取决于你的临界区平均耗时和系统负载特征。
最后提醒：自旋锁不提供排队机制，线程获得锁的顺序不确定。如果你需要 FIFO 公平性，得上 std::mutex 或基于队列的 ticket lock —— 但那就不再是纯自旋了。
