std::atomic::load必须显式指定memory_order，因默认seq_cst性能差且不总是必要；应据同步需求选relaxed（仅原子性）、acquire（配对release后保证后续访问可见）或seq_cst（强一致但开销大），错用将导致竞态或性能损耗。
std::atomic::load 的 memory_order 参数到底怎么选
直接说结论：std::atomic::load 必须显式传入 memory_order 枚举值，不传会默认用 memory_order_seq_cst，但“显式指定”不是为了语法正确，而是控制 CPU 指令生成和内存重排边界。选错会导致读取结果不可预期，或性能意外下降。
常见错误是把 memory_order_relaxed 当成“随便读”，结果在多线程里读到陈旧值；或者在需要同步的场景硬套 memory_order_acquire，却忘了配对的 store 得用 memory_order_release。
-
memory_order_relaxed：只保证原子性，不约束前后指令重排，适合计数器、统计类场景 -
memory_order_acquire：当前 load 之后的读写不能被重排到它前面，常用于“读标志位 + 访问共享数据”模式 -
memory_order_seq_cst：全局顺序一致，默认值，开销最大，但行为最直观
为什么 x86 上 memory_order_acquire 和 memory_order_seq_cst 生成的汇编常常一样
因为 x86 的内存模型本身较强（有隐式 acquire/release 语义），memory_order_acquire 在大多数情况下不需要额外的 fence 指令；而 memory_order_seq_cst 在单 load 场景下也未必插入 mfence —— 编译器会根据上下文优化。
但这不等于可以混用。ARM/AArch64 或 RISC-V 下差异立刻暴露：一个 load(memory_order_acquire) 可能生成 ldar，而 load(memory_order_seq_cst) 会多一条 dmb ish 或等效屏障。
- 别靠 x86 表现反推语义 —— 它只是“恰好够强”
- 跨平台代码必须按抽象模型写，而不是看某平台汇编是否相同
- 用
clang++ -S -O2对比不同 target（如--target=aarch64-linux-gnu）才能验证实际效果
load(memory_order_acquire) 后访问非原子变量，为什么还是可能出错
很多人以为只要用了 acquire，后续所有读操作就“安全”了，其实不然：acquire 只约束编译器和 CPU 对该 atomic 操作前后指令的重排，不保证非原子变量本身被正确发布（published）。
典型坑点：线程 A 写完 data（非原子），再 store flag（memory_order_release）；线程 B 用 load(memory_order_acquire) 读 flag，再读 data —— 这才安全。如果 A 没用 release store，B 就算用了 acquire load，data 仍可能未刷新到 B 的 cache。
-
acquire和release是一对，单独用acquire没意义 - 非原子变量必须由 release-store “带出”，不能靠 compiler barrier 或 volatile 代替
- 若用
memory_order_seq_cst，则所有 seq_cst 操作构成单一全序，可间接建立同步，但代价高
std::atomic::load 用 memory_order_relaxed 时，编译器真会优化掉重复读吗
会。尤其在循环中连续读同一个 std::atomic<bool></bool>，且没其他同步点时，Clang/GCC 都可能把它优化成一次读 + 寄存器缓存，导致死循环（即使其他线程已改写该值）。
这不是 bug，是 relaxed 的合法行为：它只要求读操作原子，不要求实时可见性。要避免，要么加 memory_order_acquire，要么插入 std::this_thread::yield()（但 yield 不解决根本问题）。
- 用
relaxed前先确认：你是否真的不需要“看到其他线程最新写入”？ - 轮询场景更推荐
std::atomic_flag+test_and_set(memory_order_acquire)或条件变量 - 调试时加
volatile强制重读只是临时手段，不能替代正确的 memory_order 选择
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
