std::is_always_lock_free 是一个编译期常量布尔值，用于判断 std::atomic<T> 是否在所有支持平台上均能无锁实现；它要求 T 为平凡可复制类型且硬件指令与标准库均支持该大小的原子操作。
std::is_always_lock_free 是什么，它能告诉你什么
std::is_always_lock_free 是一个编译期常量布尔值，定义在 <atomic> 头文件中，用于判断某个 std::atomic<T> 类型是否**在所有支持该类型的平台上都无需锁（lock-free）**。注意：它不作用于“类”，而是作用于 std::atomic<T> 的特化类型；你不能直接对自定义类（比如 struct Point { int x, y; };）查这个 trait —— 除非你先把它作为 std::atomic<Point> 的模板参数。
它的返回值为 true，仅当底层硬件指令（如 x86 的 cmpxchg16b、ARM 的 ldxr/stxr）能原生支持该类型的无锁原子操作，且标准库实现也确实用了这些指令（而非回退到互斥锁）。常见满足条件的类型包括 std::atomic<int>、std::atomic<void*>、std::atomic<std::uintptr_t> 等小整型或指针类型。
如何正确检查某个 T 是否支持 lock-free 原子操作
对任意类型 T，必须先确认 std::atomic<T> 是合法特化（即 T 是 trivially copyable 且大小适配），再查 std::atomic<T>::is_always_lock_free 或运行时 std::atomic<T>{}.is_lock_free()：
-
std::atomic<int>::is_always_lock_free—— 编译期判断，推荐用于static_assert -
std::atomic<long long>{}.is_lock_free()—— 运行时判断，适用于动态决策（如 fallback 分支） - 对自定义结构体，需确保其满足
std::atomic<T>的要求：static_assert(std::is_trivially_copyable_v<T>)且sizeof(T)通常 ≤ 指针大小（x86-64 下一般 ≤ 8 字节），否则很可能 fallback 到锁实现 - 不要写
std::is_always_lock_free<MyClass>::value—— 这个 trait 并不接受裸类型MyClass，只接受std::atomic<T>特化（C++20 起才提供std::is_always_lock_free_v<std::atomic<T>>的等价写法）
为什么 std::atomic<MyStruct> 可能 is_always_lock_free == false
即使你的结构体只有两个 int（共 8 字节），在某些平台或编译器下仍可能 fallback 到锁实现。原因包括：
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
立即学习“C++免费学习笔记（深入）”；
- 目标架构不支持该大小的原子指令（例如 ARM32 不支持 8 字节 CAS）
- 结构体内存对齐不足（
alignof(MyStruct) < sizeof(MyStruct)），导致无法映射到原子指令要求的对齐地址 - 编译器未启用对应扩展（如 GCC 需
-march=native或显式开启cx16指令集） - 标准库实现保守：即使硬件支持，某些 libc++/libstdc++ 版本仍对非标量类型默认禁用 lock-free 实现
验证方式很简单：
static_assert(std::atomic<MyStruct>::is_always_lock_free, "MyStruct must be lock-free");编译失败就说明不行 —— 这比运行时检查更早暴露问题。
替代方案：当 is_always_lock_free 为 false 时怎么办
不能原子操作 ≠ 不能线程安全。你有几种务实选择：
- 改用更小、更规整的类型：例如把
struct { int a; int b; }拆成两个独立的std::atomic<int> - 用
std::atomic<std::uint64_t>打包（需手动位运算合并/拆解字段），前提是字段总宽 ≤ 64 位且无符号 - 接受锁开销：用
std::mutex+ 普通变量，性能损失在多数场景可接受 - 使用
std::atomic_ref<T>（C++20）配合已对齐的静态存储，有时能绕过部分限制（但依然受硬件约束）
真正关键的是：别假设 sizeof(T) == sizeof(void*) 就一定 lock-free —— 对齐、指令集、ABI、标准库实现细节全会影响结果。实测 + 编译期断言，比任何经验都可靠。
