Interlocked.Exchange 会原子交换并保证内存可见性，volatile 赋值只保证可见性和禁止重排，不保证原子性
这是最根本的区别：如果你需要“读旧值 → 算新值 → 写入”这一整套动作不可打断（比如实现无锁栈、状态切换、引用替换），
Interlocked.Exchange是唯一安全选择；而
volatile只是告诉编译器和 CPU：“这个变量别缓存，每次都要从主内存读/写”，它连
i++都保护不了——因为
i++本身包含读、加、写三步，volatile 对其中任意一步都“原子”，但对整个序列毫无约束。
什么时候该用 Interlocked.Exchange，而不是 volatile 赋值？
看操作是否涉及“读-改-写”逻辑或需要返回旧值：
要替换一个引用并拿到被替换掉的旧对象（比如无锁队列头节点更新）→ 必须用Interlocked.Exchange多个线程可能同时尝试设置同一个标志（如
_currentHandler），且你希望只让第一个成功者生效 → 用
Interlocked.CompareExchange更合适，但
Exchange也常用于“强制覆盖”场景 需要确保写入后，其他线程立刻看到新值，**同时还要确保写入动作本身不会被其他线程的并发写入干扰** →
Interlocked.Exchange提供完整栅栏（full memory barrier），volatile 没有这种保障 给
volatile字段赋值（如
_flag = true）仅适合单写多读、纯状态通知场景，且写入方唯一、无依赖前序状态
volatile 写入和 Interlocked.Exchange(ref, value) 的实际行为差异
哪怕目标字段已声明为
volatile，也不能把
Interlocked.Exchange替换成普通赋值——它们底层语义完全不同：
volatile字段赋值（如
_ptr = newValue）：生成的是带 acquire-release 语义的单次写入，但不阻止其他线程在同一时刻执行自己的写入
Interlocked.Exchange(ref _ptr, newValue)：不仅写入，还返回原值；且整个操作在硬件层面是原子的（x86 上对应
XCHG指令），天然具备 full barrier 效果，等效于加了
Thread.MemoryBarrier()传参限制：
Interlocked.Exchange**不能接受 volatile 字段直接作为 ref 参数**（编译报错 CS0190），必须先去掉 volatile 修饰，或用局部变量中转——这是很多人踩坑的第一步
private volatile object _cache; private object _cacheNonVolatile; // 实际存储用非 volatile 字段 <p>// ❌ 错误：不能将 volatile 字段传给 ref 参数 // Interlocked.Exchange(ref _cache, newValue);</p><p>// ✅ 正确：用非 volatile 字段 + Interlocked Interlocked.Exchange(ref _cacheNonVolatile, newValue);</p><p>// ✅ 或用临时变量（但失去 volatile 的可见性保障，需配合其他同步） var temp = _cache; Interlocked.Exchange(ref temp, newValue); _cache = temp; // 这里又需要 volatile 写入来通知读者</p>
性能与适用边界：别为了“看起来高级”硬套 Interlocked
在高竞争、高频更新场景下，
Interlocked.Exchange比
volatile写入开销大得多（涉及总线锁定或 cache line 无效化），但它换来了确定性。反过来，如果只是后台线程轮询一个开关，
volatile bool _shouldStop就足够轻量且正确： 单写多读、无状态依赖 → 优先考虑
volatile需要返回旧值、需强顺序保证、需替换引用并防止 ABA 类问题（哪怕概率低）→ 必须用
Interlocked系列 若涉及多个字段协同更新（比如同时改
_value和
_timestamp），两者都不够，得上
lock或
SpinLock
真正容易被忽略的是：volatile 不是“弱 lock”，Interlocked 也不是“轻量 lock”——它们解决的是不同维度的问题。混用或替代，往往不是性能差一点，而是 bug 出现在压测后期、偶发超时、数据错乱，极难复现。
