C++怎么使用原子操作_C++中atomic线程安全【实战】

std::atomic 初始化必须显式，如 std::atomic<int> counter{0}；默认构造不初始化底层存储，导致未定义行为；自定义类型需满足 trivially copyable 且无用户构造函数；memory_order 应按需选择，避免滥用 seq_cst；compare_exchange_weak 需配合循环使用；atomic_ref 要求严格对齐与生命周期管理。

atomic 初始化必须显式，不能依赖默认构造

很多刚用 std::atomic 的人会写 std::atomic<int> counter;</int> 然后直接 counter++，结果运行时崩溃或值随机——因为 std::atomic 的默认构造不初始化底层存储，内存是未定义的。

• 必须显式初始化：std::atomic<int> counter{0};</int> 或 std::atomic<int> counter = ATOMIC_VAR_INIT(0);</int>（C++17 起已弃用后者，优先用花括号初始化）
• 对自定义类型（如 struct Point { int x,y; };），只有满足 trivially copyable 且无用户定义构造函数，才能用 std::atomic<point></point>，否则编译失败
• 注意：std::atomic<bool></bool> 是特例，它的默认构造会初始化为 false，但依然建议显式写 {false} 保持风格统一

load/store 用 relaxed 还是 seq_cst？看是否需要顺序保证

默认的 load() 和 store() 是 std::memory_order_seq_cst，性能最差但行为最符合直觉；实际中多数场景不需要这么强的顺序约束，乱用会拖慢多核性能。

• 计数器累加（如引用计数）：用 relaxed 就够了，只要不依赖其他内存访问顺序
• 标志位通知（如 ready_flag.store(true, std::memory_order_release) 配合 ready_flag.load(std::memory_order_acquire)）：必须成对使用 release/acquire，否则线程可能看到“部分更新”的状态
• 绝对避免在同一个 std::atomic 上混用不同 memory order 的操作——比如一个线程用 seq_cst，另一个用 relaxed，语义上没问题，但调试和推理成本陡增，容易漏掉同步点

compare_exchange_weak 和 strong 的区别不只是“失败概率”

compare_exchange_weak 可能伪失败（spurious failure），即值没变也返回 false；strong 保证只在值真不等时失败。但关键不是“哪个更可靠”，而是循环写法是否健壮。

PaperFake

AI写论文

下载

• 几乎总该用 weak + 循环：它在 x86 上通常编译为单条 cmpxchg 指令，而 strong 在某些平台（如 ARM）可能隐含重试逻辑，反而更重
• 正确写法是：

  int expected = counter.load();
  while (!counter.compare_exchange_weak(expected, expected + 1)) {
      // expected 已被更新为当前值，继续重试
  }

• 如果循环体里有复杂计算或可能阻塞的操作，才考虑 strong 避免反复执行副作用——但这种情况本身就该重构，别把业务逻辑塞进 CAS 循环

atomic_ref 是 C++20 新特性，别在旧项目里硬套

有人看到 std::atomic_ref 能对栈/堆变量做原子操作，就想用来“给已有结构体字段加线程安全”，结果编译不过或运行出错。

立即学习“C++免费学习笔记（深入）”；

• 它要求所引用对象的地址必须满足对齐要求（通常是 alignof(T)），普通 int a; 在栈上不一定满足；用 alignas 显式对齐才能安全使用
• 生命周期必须严格长于 atomic_ref 实例——不能对临时变量、局部数组元素或即将析构的对象取 atomic_ref
• MSVC 2019 16.10+、GCC 11、Clang 12 才开始支持；C++17 项目强行启用会触发未定义行为，不是报错那么简单