std::exchange是否针对原子类型特化？如何实现通用交换逻辑

1. 标准库是否为原子类型提供std::exchange特化？ #

没有。
标准定义的默认std::exchange实现逻辑等价于如下代码：

template<class T, class U = T>
T exchange(T& obj, U&& new_value) {
    T old_val = std::move(obj);
    obj = std::forward<U>(new_value);
    return old_val;
}

对原子类型调用std::exchange时，不会自动调用std::atomic_exchange，只会执行上述默认逻辑：分「读取旧值」「写入新值」两个独立步骤执行。

2. 为什么标准不提供这个特化？ #

标准制定过程中确实有过相关提案，但最终未被采纳，核心原因有三点：

• 内存序参数缺失：原子的exchange操作需要明确指定内存序，默认的std::memory_order_seq_cst虽然安全，但在很多场景下会带来不必要的内存屏障开销，而std::exchange的现有接口没有预留内存序入参，用户无法按需调整内存序，强行特化会导致性能和灵活性问题。
• 语义边界不清晰：std::exchange支持传入与目标类型不同的新值类型（第二个模板参数为独立的U），如果新值需要复杂的类型转换，转换过程无法纳入原子操作的保护范围，原子性的边界无法明确界定，容易产生误导。
• 避免静默语义变更：C++标准库对并发相关的强语义操作始终保持显式原则，如果静默为原子类型替换原子实现，用户在普通类型和原子类型间切换时，代码语义会在无感知的情况下发生变化，既可能带来意外的性能开销，也可能掩盖并发设计上的问题。

3. 原子类型使用默认std::exchange的线程安全风险 #

把计数器改为原子类型后，原有基于std::exchange的代码存在明确的线程安全问题。
默认实现的读、写是两个独立的原子操作，中间没有原子性保护：线程读取旧值后、写入新值前，完全可能被其他线程插入修改操作，导致返回的旧值与变量实际状态不匹配、更新丢失。举个典型场景：

• 计数器初始值为10，线程A调用std::exchange(cnt, 0)，刚读完旧值10
• 线程B切入，将计数器修改为15
• 线程A恢复执行，将计数器设为0，返回旧值10
  整个过程中计数器曾经到达15，但线程A拿到的旧值完全没有反映这个状态，重置操作也不是原子的，不符合多线程场景的预期。

4. 通用安全交换函数的实现方式 #

不要尝试在std命名空间下为原子类型添加std::exchange特化，这属于未定义行为。可以自己实现一个通用交换函数，通过编译期分支自动适配普通类型和原子类型，C++17及以上版本的实现非常简洁：

#include <utility>
#include <atomic>
#include <type_traits>

template<class T, class U = T>
T safe_exchange(T& obj, U&& new_val,
                std::memory_order order = std::memory_order_seq_cst)
{
    if constexpr (std::is_atomic_v<T>) {
        // 原子类型调用原生原子exchange接口，支持自定义内存序
        return obj.exchange(std::forward<U>(new_val), order);
    } else {
        // 普通类型走标准库默认exchange逻辑
        return std::exchange(obj, std::forward<U>(new_val));
    }
}

这个实现的优势：

• 对原子类型自动使用原子交换操作，保证操作的原子性
• 预留了内存序参数，默认使用最安全的全序屏障，用户也可以根据场景选择更宽松的内存序（比如重置纯计数场景用std::memory_order_relaxed即可获得更好性能）
• 对普通类型完全兼容原有std::exchange的行为，不需要修改存量代码

如果需要兼容C++17之前的版本，可以通过SFINAE或者模板特化实现相同的分发逻辑，只是写法会更繁琐。

内容的提问来源于stack exchange，提问作者Quimby