因为 std::string 不是平凡可复制类型，std::atomic 要求模板参数 T 必须满足 trivially copyable，否则编译失败；可行替代方案包括 std::atomic 或无锁队列。
atomic为什么不能直接用 std::atomic<:string>
因为 std::atomic 要求模板参数 T 必须是 trivially copyable（平凡可复制）类型，而 std::string 不满足——它内部有动态分配、拷贝构造和析构逻辑。编译器会直接报错：static_assert failure 或类似 “std::string is not a trivially copyable type”。
常见误操作是想当然地写：
std::atomic msg{"hello"}; // 编译失败
可行替代方案：
- 用
std::atomic<:string> + 手动管理堆内存（不推荐，易泄漏
）
- 改用
std::shared_ptr<:string>，因为 std::atomic<:shared_ptr>> 是标准支持的特化（C++20 起完全可用；C++11/14/17 中部分实现支持，但需查文档）
- 对字符串内容做无锁设计时，优先考虑环形缓冲区或 lock-free queue（如
moodycamel::ConcurrentQueue），而非强行原子化 string 对象
load() 和 store() 的 memory_order 参数怎么选
默认是 std::memory_order_seq_cst（顺序一致性），最安全但性能开销最大；实际中多数场景可降级以提升吞吐。
典型选择依据：
- 纯标志位（如
std::atomic ready{false}）：用 memory_order_acquire（load） + memory_order_release（store）即可构成 acquire-release 同步对，避免重排且成本低
- 计数器累加（如引用计数）：用
memory_order_relaxed —— 只需保证原子性，不依赖与其他内存访问的顺序
- 需要全局唯一顺序（如日志序列号）：必须用
memory_order_seq_cst
错误示例（看似省事，实则破坏同步语义）：
flag.store(true, std::memory_order_relaxed); // 若另一线程靠 flag.load() 判断数据就绪，这里会导致读到 flag==true 但数据未写完
compare_exchange_weak() 为什么总要写在 while 循环里
因为 weak 版本允许「伪失败」（spurious failure）：即使当前值匹配，也可能返回 false（尤其在 ARM/PowerPC 等弱内存模型 CPU 上）。它比 strong 版本快，但不可靠单次调用。
正确模式是：
int expected = 0;
while (!counter.compare_exchange_weak(expected, 1, std::memory_order_acq_rel)) {
// 失败后 expected 已被更新为当前实际值，下次循环自动重试
}
关键点：
- 不要手动重置
expected，否则可能无限循环
- 若逻辑不允许重试（如只争一次的资源抢占），改用
compare_exchange_strong()
-
compare_exchange_weak() 在循环中配合 memory_order_acq_rel 是 lock-free 算法最常用组合
std::atomic_flag 和 bool 类型 atomic 的区别
std::atomic_flag 是 C++ 原子操作中最底层、最轻量的类型，仅支持 test_and_set() 和 clear()，且保证无锁（lock-free）。而 std::atomic 是通用封装，可能在某些平台回退到互斥锁模拟（可通过 is_lock_free() 检查）。
适用场景：
- 手写自旋锁、futex 封装、极简信号量：用
std::atomic_flag，因为它强制 lock-free 且无构造/析构开销
- 普通布尔状态标记（如
shutdown_requested）：用 std::atomic 更直观，可读性好，性能差异微乎其微
- 初始化注意：
std::atomic_flag 默认处于 set 状态，必须显式 .clear(std::memory_order_relaxed) 才能使用
容易忽略的一点：很多开发者以为 atomic_flag 更“高级”，其实它只是更原始——没有 load/store 接口，也不能直接赋值，所有操作都得通过 test_and_set/clear 语义完成。
