std::atomic::is_lock_free() 返回 false 表示当前对象的原子操作实际使用内部互斥锁，非无锁；它在运行时探测真实能力，而非编译期保证，且受对齐、平台、ABI 等影响。
直接看 std::atomic<t>::is_lock_free()</t> 返回值——它不是编译期保证，也不是“理论上能无锁”，而是运行时真实能力的快照。返回 false 就说明你正在用锁，别再幻想 lock-free 了。
怎么查？别只看编译期常量
std::atomic<t>::is_always_lock_free</t> 是编译期常量，但只对极少数类型为 true（比如 std::atomic_flag 或某些平台上的 std::atomic<int></int>）。它不反映你当前 ABI、对齐、目标架构的真实行为。
真正该调的是成员函数 is_lock_free()，它在运行时探测实际实现：
std::atomic<long long> x;
if (!x.is_lock_free()) {
// 这里大概率 fallback 到内部 mutex，别硬上
}
- 即使
T是int，若未按平台要求对齐（例如 x86-64 上未 8 字节对齐），is_lock_free()也可能返回false - 结构体哪怕只有两个
int，在多数编译器+平台组合下都 fallback，is_lock_free()几乎必为false - 不要依赖
sizeof(T) <= sizeof(void*)推断——ARM64 对 16 字节原子操作支持有限，std::atomic<__m128>很可能锁住
为什么 is_lock_free() 返回 false 却没报错？
因为标准允许 fallback：当硬件不支持某类型的无锁原子操作时，std::atomic 可以悄悄用一个内部互斥锁兜底。你调 store()、load() 看似正常，实则已进入锁路径。
C++ Code Review Master
下载
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
立即学习“C++免费学习笔记（深入）”；
- 典型症状：高争用下性能骤降，
perf record -e 'syscalls:sys_enter_futex'能看到大量 futex 系统调用 - 调试技巧：加个断点在
std::atomic<T>::store，进汇编看有没有lock xchg或mfence；如果看到pthread_mutex_lock调用，就坐实了 -
std::atomic_is_lock_free(&x)宏和成员函数等价，但宏不能用于非对象上下文（比如模板参数推导）
is_lock_free() 为 false 时，还能用 std::atomic 吗？
能，但得换思路——它此时只是“线程安全的普通变量”，不是 lock-free 原语。继续用它没问题，但别把它塞进无锁算法核心。
- 计数器场景：用
std::atomic<int>没问题，fetch_add仍线程安全，只是争用激烈时不如真正的无锁计数器 - 标志位场景：若
std::atomic<bool>返回false，优先换std::atomic_flag（它强制无锁且更轻量） - 结构体场景：别写
std::atomic<MyStruct>，拆成多个std::atomic<int>+ CAS 协调，或改用std::mutex显式保护 - 跨平台发布前务必在目标机器上跑一次
is_lock_free()检查——x86-64 开发机上 true，ARM64 生产环境可能 false
内存序和 is_lock_free() 的关系容易被忽略
is_lock_free() 只管“有没有锁”，不管内存序开销。即使返回 true，选错 memory_order 一样拖慢性能。
-
memory_order_seq_cst在 x86 上隐含mfence，比memory_order_acquire/memory_order_release重得多 - ARM/AArch64 上，
seq_cst可能触发全局屏障，影响其他无关 cache line，别无脑用 - 如果你的类型是 lock-free，但所有操作都用
seq_cst，那性能瓶颈很可能不在原子性，而在内存序滥用
