std::atomic::exchange 不会阻塞线程，它是无锁原子操作，底层通常编译为单条 CPU 指令；仅当 is_lock_free() 为 false（如对齐不足的自定义类型）时可能退化为互斥量实现而产生阻塞。
std::atomic::exchange 会阻塞线程吗？
不会。std::atomic::exchange 是一个无锁（lock-free）原子操作，底层通常编译为单条 CPU 指令（如 x86 的 xchg 或 lock xchg），不涉及互斥量或系统调用，因此不会引起线程阻塞或调度切换。
但要注意：如果目标 std::atomic 对象在硬件层面不支持 lock-free（例如某些对齐不满足要求的自定义类型），is_lock_free() 返回 false，此时标准库可能退化为内部使用互斥量实现——这时才可能有阻塞风险。内置整型（int、long 等）在主流平台几乎总是 lock-free。
- 用
my_atomic.is_lock_free()在运行时确认是否真正无锁 - 编译期可用
std::atomic<int>::is_always_lock_free</int>静态常量判断 - 避免对未对齐或过大类型（如
std::atomic<:array>></:array>）盲目调用exchange
exchange 和 store + load 的行为差异在哪里？
exchange 是“读-改-写”一步完成的原子操作；而分开调用 store 和 load 会产生两个独立的原子动作，中间存在竞态窗口——其他线程可能在这之间修改值。
典型误用场景：想用 old = atomic.load(); atomic.store(new_val); 实现“获取旧值并设新值”，这在多线程下无法保证原子性。
立即学习“C++免费学习笔记（深入）”；
-
exchange返回旧值，且整个置换过程不可分割 - 等价于“原子地读出当前值，并写入新值”，语义上比 CAS 更简单直接
- 没有失败重试逻辑，适合不需要条件判断的强制替换场景（如状态机切换、资源句柄移交）
如何正确传递参数和选择内存序？
exchange 接收两个参数：要写入的新值，以及可选的 std::memory_order。默认是 std::memory_order_seq_cst，最严格也最安全；但若已知上下文无依赖关系，可降级以提升性能。
常见组合：
- 仅需保证本操作原子性（如交换标志位），用
std::memory_order_relaxed - 需要确保之前所有写操作对其他线程可见（如交换指针前已初始化对象），用
std::memory_order_release - 需要确保之后读到的数据是交换后生效的（如交换后立即读取新结构体字段），配合
std::memory_order_acquire - 跨线程同步关键状态（如启动/停止信号），仍建议用默认
std::memory_order_seq_cst
示例：flag.exchange(true, std::memory_order_acq_rel) 表示“获取旧值并写入 true”，同时兼具 acquire 和 release 语义。
容易被忽略的类型约束和隐式转换陷阱
exchange 要求传入值的类型必须与原子对象模板参数**精确匹配**，不进行用户定义类型转换，也不接受窄化隐式转换。
比如 std::atomic<uint32_t> counter;</uint32_t> 不能传 int 或 unsigned short 直接调用 exchange，否则编译失败。
- 显式转换：用
counter.exchange(static_cast<uint32_t>(val))</uint32_t> - 统一变量类型：声明时就用
uint32_t，避免混用int/unsigned - 注意
bool原子对象：传1或true都可以，但counter.exchange(2)会编译失败（2 不是 bool） - 自定义类型必须满足 trivially copyable 且满足对齐要求，否则
exchange不可用
实际调试中，这类类型错误往往表现为模板实例化失败，错误信息里会高频出现 no matching function for call to 'exchange'。
