C++ std::atomic::exchange用法 _ 原子交换操作实现互斥锁【详解】-C++-PHP中文网

std::atomic::exchange不能实现互斥锁，因为它无条件原子写并返回旧值，缺乏“仅当未被占用才成功”的条件判断；而compare_exchange_weak通过比较并交换满足锁的排他性要求。

c++ std::atomic::exchange用法 _ 原子交换操作实现互斥锁【详解】

std::atomic::exchange 为什么不能直接实现互斥锁

它不能。exchange 是无条件原子写+返回旧值，但互斥锁的核心语义是“仅当当前未被占用时才成功获取”，这需要条件判断——而 exchange 没有判断逻辑。你用 exchange(true) 把一个 std::atomic<bool></bool> 设为 true，不管原来是不是 true，它都成功返回旧值。这相当于“强行上锁”，不满足锁的排他性要求，多个线程会同时认为自己拿到了锁。

compare_exchange_weak 才是实现自旋锁的正确入口

真正能模拟锁行为的是 compare_exchange_weak：它先读当前值，再比对，仅当匹配才写入新值，并原子地完成整个过程。失败时还能把最新值回填到期望变量里，方便重试。

典型自旋锁结构体中，lock() 循环调用 flag.compare_exchange_weak(expected, true)，其中 expected 初始为 false
如果 flag 当前是 false，操作成功，线程获得锁；如果是 true，操作失败，expected 被更新为 true，循环继续
必须用 weak 版本（而非 strong），因为某些平台（如 ARM）上 weak 对应单条硬件指令，性能更好；且循环重试天然容忍虚假失败
解锁只需 flag.store(false, std::memory_order_release)，配合 acquire 内存序保证临界区前后指令不被重排

exchange 的真实适用场景：状态翻转与一次性通知

exchange 不适合做锁，但特别适合“只关心旧状态、不关心是否被竞争”的场景。它的优势在于确定性——一定成功、一次完成。

C++ Code Review Master

组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。

下载

服务关闭信号：service_shutdown_requested.exchange(true)，确保无论之前是否已请求关闭，现在都生效，并拿到“是否首次触发”的判断依据
清空并接管资源：比如一个原子指针 std::atomic<node> head</node>，head.exchange(nullptr) 可安全取出当前链表头，供本线程独占处理，后续再重建
计数器批量归零：counter.exchange(0) 比 load() + store(0) 更简洁，避免中间被其他线程修改
注意：若用在指针类型上，需确保旧值所指对象生命周期可控，否则可能造成悬垂指针

内存序选错会让 exchange 失去同步意义

默认 std::memory_order_seq_cst 安全但稍重；实际中常可降级，但必须理解代价。

用于标志位翻转（如开关）时，exchange(true, std::memory_order_acq_rel) 就足够：它既阻止前面的读写乱序到交换之后（release），也阻止后面的读写乱序到交换之前（acquire）
若只是记录日志或调试计数，std::memory_order_relaxed 即可，性能最高，但不提供任何跨线程同步保证
绝对不要在释放锁语义中用 relaxed：比如 unlock() 若只用 relaxed store，临界区内的写操作可能被重排到 unlock 之后，导致其他线程看到不一致状态

exchange 的简洁性容易让人忽略它的“无条件”本质——它不是锁的简化版，而是另一类问题的专用解。用错地方，轻则逻辑错误，重则引发竞态；用对地方，代码干净，性能突出。关键在分清：你要的是“抢占”，还是“交接”。