根本原因是内存序使用不当，而非std::atomic失效；默认seq_cst安全但开销大，显式使用relaxed等宽松序会导致指令重排和缓存不同步，引发读到旧值或compare_exchange_weak虚假失败。
为什么std::atomic看似用了却还是读到旧值？
根本原因不是std::atomic失效，而是你没用对内存序（memory_order）。默认的std::memory_order_seq_cst虽安全但开销大，而一旦显式指定更宽松的序（比如memory_order_relaxed），编译器和CPU就可能重排指令、缓存不及时刷新，导致另一线程看到“过期”值。
典型现象：一个线程反复store()新值，另一个线程调用load()却长期卡在旧值；或compare_exchange_weak()总失败，不是因为值真没变，而是本地缓存没同步。
- 检查所有
load()和store()是否用了匹配的内存序——写用memory_order_release，读用memory_order_acquire，才能建立synchronizes-with关系 - 避免在关键路径上滥用
memory_order_relaxed，尤其当读写逻辑存在隐含依赖（比如先写标志位再写数据） - 用
std::atomic_thread_fence()补救时，必须成对出现（acquire+release），且位置要卡在依赖边界上
如何确认是缓存一致性问题而非逻辑错误？
先排除代码逻辑 bug：把所有std::atomic临时换成普通变量 + 全局互斥锁，如果问题消失，基本锁定是原子操作语义误用；如果问题还在，说明是业务逻辑竞态，和原子性无关。
真正要验证缓存同步，得看硬件行为。x86/x64 上acquire/release实际会插入lfence/sfence，但 ARM/AArch64 不同，需更谨慎。
立即学习“C++免费学习笔记（深入）”；
- 在 ARM 平台上，
memory_order_acquire不等于__asm__ volatile("dmb ish" ::: "memory")，后者更强——别想当然移植 x86 代码 - 用
valgrind --tool=helgrind跑，它能报出“data race on atomic variable”，这是最直接的证据 - 加日志时别只打值，要打
std::this_thread::get_id()和时间戳（用std::chrono::steady_clock::now()），否则看不出执行时序
compare_exchange_weak循环失败却不退出？
这不是 bug，是设计使然：compare_exchange_weak允许虚假失败（spurious failure），尤其在高争用或某些 CPU 架构上。如果你写成if (a.compare_exchange_weak(old, new)) break;，很可能永远进不了break。
正确写法永远是循环，且必须更新old值：
int expected = a.load();
do {
if (a.compare_exchange_weak(expected, desired)) break;
} while (expected != desired);
注意：expected在失败后已被compare_exchange_weak更新为当前真实值，下一轮循环直接复用即可，不用重新load()。
- 别用
compare_exchange_strong替代——它只是减少虚假失败，不消除，且在某些平台性能更差 - 如果
desired依赖expected计算（比如自增），必须在循环内重算，不能提至循环外 - LL/SC 架构（如 ARM）上
weak版本更贴近硬件原语，强行用strong可能触发软件模拟，反而慢
调试时哪些工具和配置能快速暴露问题？
靠肉眼扫代码几乎无效。真正有效的是编译器+运行时组合技：
- Clang/GCC 加
-fsanitize=thread，它会在运行时拦截所有未同步的共享访问，比helgrind更准、更快，但要求全量编译（包括第三方库） - 用
std::atomic<T>::is_lock_free()检查是否真走硬件原子路径——返回false意味着内部用了互斥锁，那根本不是你想象的“无锁”行为 - 在关键原子操作前后插
std::atomic_thread_fence(std::memory_order_seq_cst)临时“加固”，如果问题消失，说明原内存序太松；但别留着上线，这只是诊断手段
最常被忽略的一点：std::atomic_flag是唯一保证无锁的类型，其他std::atomic<T>是否无锁取决于T大小和平台对齐——比如atomic<uint64_t>在 32 位 ARMv7 上大概率不是lock_free，这时load()本质是带锁的函数调用，性能和语义都变了。
