std::atomic_flag 是唯一强制无锁的原子类型，仅提供 test_and_set/clear，接口极简且映射到底层位操作；std::atomic 支持完整值语义和运算符，但允许锁回退（尽管 x86-64 上通常无锁）。
std::atomic 和 std::atomic_flag 的底层指令差异
两者在 x86-64 上通常都编译为单条 lock xchg 或 lock cmpxchg 指令，但关键区别在于：
std::atomic_flag 是唯一被要求「无锁（lock-free）」的原子类型，C++ 标准强制其实现必须基于硬件原语（如 xchg、test-and-set），不能回退到内部互斥量；
而 std::atomic 允许实现用锁模拟（虽然主流编译器如 GCC/Clang 在 x86 上实际都生成无锁代码）。
这意味着在极端平台（如某些嵌入式 ARMv7 配置）上，std::atomic 可能慢一个数量级，而 std::atomic_flag 仍保证最快路径。
std::atomic_flag 的限制导致它更轻量
std::atomic_flag 只提供 test_and_set() 和 clear()，不支持读取当前值（除非用 test_and_set(std::memory_order_acquire) + 回滚）、不支持比较交换（CAS）、也不支持赋值语法。这种极简接口让编译器无需维护额外状态或做值合法性检查（比如 bool 的 0/1 归一化），直接映射到最底层的位操作指令。
std::atomic 则需处理：
- 值语义（load() 返回 bool，需确保返回值是标准 true/false，而非任意非零字节）
- 赋值运算符重载（a = true 必须等价于 store(true)）
- 可能的 padding 对齐优化（sizeof(std::atomic 通常是 1，但对齐可能是 4）
实测性能差距通常可忽略，但场景决定选择
在现代 x86-64 + 优化编译下（-O2），两者的汇编输出几乎一致，微基准测试（如循环 1e9 次 store(true, mo_relaxed)）差异在 ±2% 内。真正影响性能的是使用方式：
- 若只需「设置一次、查询多次」或自旋锁，用 std::atomic_flag —— 它明确表达意图，且 test_and_set() 天然适合 spinlock
- 若需条件判断（如 if (flag.load()) { ... }）、CAS 循环或与逻辑运算混用，std::atomic 更自然，避免手动 decode test_and_set() 返回值
- 不要为了“理论上快一点”而强行用 std::atomic_flag 模拟 load()：写成 flag.test_and_set(mo_acquire); flag.clear(mo_release); 是错的，会改变状态且开销翻倍
// ✅ 正确：atomic_flag 用于自旋锁
std::atomic_flag lock = ATOMIC_FLAG_INIT;
while (lock.test_and_set(std::memory_order_acquire)) {
// 自旋
}
// ... 临界区 ...
lock.clear(std::memory_order_release);
// ✅ 正确：atomic 用于开关控制
std::atomic ready{false};
// 线程 A：
ready.store(true, std::memory_order_release);
// 线程 B：
if (ready.load(std::memory_order_acquire)) {
do_work();
}
最容易被忽略的点：ATOMIC_FLAG_INIT 和静态初始化
std::atomic_flag **没有默认构造函数**，必须用 ATOMIC_FLAG_INIT 初始化（C++20 起可用 std::atomic_flag{};，但老代码仍常见宏）。漏掉初始化会导致未定义行为，且这种 bug 在 ASan/UBSan 下也不报 —— 因为它是纯位模式，无构造函数调用痕迹。而 std::atomic 支持 std::atomic，更容错。所以“更快”是有代价的：接口越原始，越依赖程序员不犯低级错误。
