1. 为什么说原子操作是并发编程的“地基”在 C#.NET 里写多线程代码最先遇到的那道坎儿往往不是死锁而是变量莫名其妙地“变脏”。你可能见过这种场景两个线程同时执行counter最后值却比预期小或者一个线程读到的共享引用既不是旧值也不是新值而是半初始化状态。原因很简单这种指令在 CPU 层面根本不是一步完成的它要分为“读-改-写”三拍三拍之间一个线程被打断另一个线程插进来数据就对不上了。这时候最常见的第一反应是加锁。lock确实能解决问题但它很重它会阻塞线程、涉及上下文切换还会引入潜在的锁顺序问题。而Interlocked.Exchange这类原子操作走的是另一条路它让 CPU 直接保证“读-改-写”这三步作为一个整体执行中间谁也不能插队。用大白话说就是给变量装了一扇只能一个人通过的门而且是硬件级的。这篇文章想跟你聊透Interlocked.Exchange包括它的运行原理、在 C#.NET 里的具体用法、适合解决的并发场景以及我这些年踩过的坑。不管你是刚接触多线程的新手还是写了不少并发代码但总觉得哪儿没搞明白的老手这篇文章都能给你一些新的视角。2. 原子操作的核心思路为什么不能用 lock 代替一切2.1 lock 与 Interlocked 的底层差别很多人会把原子操作和锁混为一谈觉得“反正都是让并发安全”。两者目标一致但成本模型差异巨大。lock关键字在 JIT 编译后对应的是Monitor.Enter/Monitor.Exit它靠的是内核对象或用户态自旋等待来获取独占权。一旦线程拿不到锁它会进入阻塞状态由操作系统调度器负责唤醒。这个过程可能涉及用户态到内核态的切换耗时通常在微秒级别虽然看起来不多但在高频调用场景下会被放大很多倍。Interlocked系列方法则不同它直接映射到 CPU 提供的原子指令比如 x86 平台的lock xchg、lock cmpxchg。这些指令在执行期间会锁定总线或缓存行保证操作的原子性而且整个过程不会让线程休眠。你可以把lock想象成“我去银行柜台办业务拿号排队办完离柜”而Interlocked是“我在自助柜员机上操作系统保证我这一步操作不会和别人交错”。所以什么时候用锁、什么时候用原子操作不是喜好问题而是成本问题。如果临界区里有大量复杂逻辑、需要多步读写那必须用lock因为原子操作只能覆盖“单个变量上的单次操作”。如果只是修改一个计数、切换一个状态、交换一个引用那Interlocked显然更轻量、更可控。2.2 Exchange 在 Interlocked 家族中的特殊位置Interlocked类里常用方法不少Increment、Decrement、Add、Exchange、CompareExchange很多人觉得Exchange就是平凡无奇的赋值其实它是整套无锁编程中承上启下的关键一环。Interlocked.Exchange的语义非常纯粹把一个值赋值给目标变量然后返回这个变量原来的值。这个操作是原子的不可分割。它背后的指令是xchg在 x86 上xchg指令自带 lock 前缀CPU 自动锁定所以连显式加锁都不用。它最大的价值不是你写了个新值而是你能“安全地拿走旧值”。这个特性在无锁队列、自旋锁、引用交换等领域是核心基石。举个例子你要实现一个自旋锁最朴素的办法是用Interlocked.Exchange将状态位从 0 换成 1如果返回的旧值是 0说明锁拿到手了如果返回的旧值是 1说明锁被别人占着继续循环。没有Exchange你得用“读状态写状态”两个步骤而这两个步骤之间必然有空隙锁就可能被别人抢走。听起来很基础但这正是无锁编程和普通赋值之间微妙而关键的差别。3. Interlocked.Exchange 的完整使用姿势与细节3.1 所有重载与常见参数说明Interlocked.Exchange在 .NET 中有多个重载覆盖了基本值和引用类型重载说明Interlocked.Exchange(ref int loc, int value)交换 32 位整数Interlocked.Exchange(ref long loc, long value)交换 64 位整数Interlocked.Exchange(ref float loc, float value)交换单精度浮点数Interlocked.Exchange(ref double loc, double value)交换双精度浮点数Interlocked.Exchange(ref IntPtr loc, IntPtr value)交换指针大小的整数值Interlocked.Exchange(ref object loc, object value)交换对象引用Interlocked.ExchangeT(ref T loc, T value) where T : class泛型形式用于任意引用类型注意一个细节Interlocked.Exchange的泛型重载只支持引用类型where T : class因为值类型可能包含多个字段无法用一条 CPU 指令保证整体原子交换。如果你真的想原子交换一个含多个字段的结构体那只能靠锁或者用Interlocked操作结构体内部的单个字段。从 .NET Core 3.0 开始还增加了Interlocked.Exchange(ref bool location, bool value)底层也是按整数处理的方便了状态标志位操作。在旧版本中你只能通过int或long来模拟 bool 交换。3.2 返回值究竟有什么用Interlocked.Exchange的返回值是最容易被人忽略的点。很多人会这么写Interlocked.Exchange(ref _state, 1);然后以为这样就完成了状态设置。但你没用它的返回值相当于把Exchange当作平凡的写操作。但实际上这个方法的返回值代表着“上一个值”而这个旧值往往才是判断逻辑的关键。比如在线程间传递“当前占用者”这个引用类型时你想把一个新对象放入共享字段但前提是你得知道之前的对象是谁从而对它做资源释放或通知。这时候就必须用返回值拿回旧引用var oldObject Interlocked.Exchange(ref _sharedObject, newObject); if (oldObject ! null) { // 对旧对象做清理 }如果没有原子交换光靠普通赋值是拿不到安全旧值的——在你赋值的前一刻旧值可能已经被别的线程换掉了。也就是说Exchange有两种能力一是“写入”二是“取出并标记”。当你把两者看在一起时才能理解为什么它叫“Exchange”而不叫“Assign”。3.3 内存屏障语义你不需要手动加 fence在 .NET 的弱内存模型下编译器、JIT 以及 CPU 都可能对指令进行重排。如果只是普通读写可能出现“先看到新值、后看到旧值”之类的乱序现象。Interlocked.Exchange的文档说明它提供了全栅栏full fence语义也就是说在它之前的写操作不会被移到它之后在它之后的读操作不会被移到它之前。这比单纯保证“原子性”要强得多。举个例子如果不用内存屏障生产者在写入共享数据时消费者线程可能因为重排而先读到数据就绪标志再读数据时数据还没写进去。但如果你用Interlocked.Exchange来设置就绪标志等于在数据写入之后插了一道栅栏消费者无法越过这道栅栏提前读数据。这就是为什么很多无锁队列会专门用Interlocked.Exchange来发布数据它能同时解决“写入的可见性”和“读取的顺序性”两个问题。所以你不需要在Interlocked.Exchange之外再额外用Thread.MemoryBarrier()那反而显得多余。除非你在区分Acquire和Release语义的场景里需要用 .NET 8 新出的Interlocked.MemoryBarrierProcessWide或者Volatile系列方法做更细粒度的控制——但大多数业务代码用不到那个级别。4. 从零写一个自旋锁Interlocked.Exchange 的实战推演4.1 自旋锁的朴素实现很多人学自旋锁时会看到类似下面的代码private int _lockFlag 0; // 0 表示未锁定1 表示已锁定 public void Enter() { while (Interlocked.Exchange(ref _lockFlag, 1) 1) { // 自旋等待可以加 Thread.Sleep(0) 或 Yield Thread.Yield(); } } public void Exit() { Interlocked.Exchange(ref _lockFlag, 0); }这看起来很简单但里面有几个细节值得展开说。第一Enter里必须是while (Interlocked.Exchange(...) 1)而不是if。假设两个线程同时调用Interlocked.Exchange只有一个线程会得到旧值 0另一个会得到旧值 1那么后者必须继续循环重试直到前者释放锁。如果你只检查一次拿不到锁就直接往下执行等于锁形同虚设。第二自旋等待期间不能真的空转死循环。在多核环境里Thread.Yield()会主动让出当前线程的时间片让同一 CPU 上的其他线程有机会运行而Thread.Sleep(0)会强制调度器切换到其他就绪线程。在实际场景中如果临界区很短自旋锁通常直接用SpinWait结构它混合了自旋和让策略能在性能和占用之间取得平衡。用Thread.SpinWait的典型写法是SpinWait spin new SpinWait(); while (Interlocked.Exchange(ref _lockFlag, 1) 1) { spin.SpinOnce(); }4.2 用 Exchange 实现原子状态机自旋锁只是最浅层的应用。实际项目中Interlocked.Exchange经常用来实现更复杂的无锁状态机。比如一个缓存对象的生命周期0 未初始化1 初始化中2 可读取3 已释放。如果两个线程同时尝试初始化缓存肯定只能允许一个成功。最安全的方法是private int _state 0; private MyCache _cache; public MyCache GetOrCreate() { if (_cache ! null) return _cache; // 尝试把状态从 0 换成 1 if (Interlocked.CompareExchange(ref _state, 1, 0) 0) { try { _cache BuildCache(); // 将状态更新为“可读取” Interlocked.Exchange(ref _state, 2); return _cache; } catch { Interlocked.Exchange(ref _state, 0); throw; } } // 另一个线程正在构建自旋等待它完成 while (Interlocked.Exchange(ref _state, _state) ! 2) { Thread.Yield(); } return _cache; }这里有一个很多人没注意到的技巧Interlocked.Exchange(ref _state, _state)看起来像是自己换自己毫无意义但它实际上是在执行一次原子的读操作并且带有读屏障语义能确保每次循环都拿到最新状态值。虽然更推荐直接用Volatile.Read但在某些代码库中看到这种写法也很正常。这个场景里Interlocked.Exchange的价值不只是把状态改成 2还在于它前面的_cache BuildCache()写操作在状态写之前就完成了并且通过 Exchange 的栅栏语义发布给其他线程。这就是上面说的“发布数据”的一种体现。4.3 引用交换的无锁实现再举一个更贴近业务的例子配置热更新。后台线程定期从远端拉取最新配置生成新的配置对象然后把它整体替换到共享字段上而多个业务线程需要随时读取当前配置。如果用锁做每次都锁一下读多写少时会放大开销。用Interlocked.Exchange可以做到无锁发布public sealed class ConfigManager { private Settings _current; public Settings Current Volatile.Read(ref _current); public void Publish(Settings newSettings) { // 把新配置发布为当前配置 Interlocked.Exchange(ref _current, newSettings); } }Settings是不可变对象所有字段在构造时赋值之后不能再改。这样读者线程拿到一个引用后可以放心使用因为那个对象不会变写者线程只需要原子地交换引用就能做到多线程安全。这也是无锁编程里最经典的不变量组合不可变对象 原子引用交换。注意我这里读Current时用了Volatile.Read而不是直接return _current。虽然Interlocked.Exchange写入时的栅栏能保证写入对所有线程可见但读者边的读取如果没有栅栏理论上可能读到过期数据。在 x86 上普通读大概率不会出问题但在 ARM 等弱内存模型上就可能踩坑。所以读共享引用时别省那一下。5. 这些坑我全都踩过Interlocked.Exchange 的边界与误区5.1 它不能保证“复合操作”的原子性这是新手最容易混淆的点。Interlocked.Exchange只能保证“单个变量的单次交换”是原子的。如果你要做的是“先判断某个条件再交换另一个变量”那这两步整体就不是原子的。典型的错误案例// 判断库存足够然后扣减 if (_stock count) { Interlocked.Exchange(ref _stock, _stock - count); }这段代码在并发下必然出错。两个线程可能同时检查到_stock10, count8都认为足够然后分别执行 Exchange最后_stock变成 210-8 和 10-8 都基于 10而不是正确的 -6实际应扣 16失败或 0。因为检查和使用之间的空隙别的线程插进来了。对于这种场景你需要用Interlocked.CompareExchange做 CAS比较并交换在循环中不断尝试直到成功while (true) { int current _stock; if (current count) return false; int newValue current - count; if (Interlocked.CompareExchange(ref _stock, newValue, current) current) return true; }这里不再用Exchange而是CompareExchange因为它能确保“如果值没变就交换”这一步是原子的。所以理解Exchange的边界很重要它适合“无条件地拿走旧值、放入新值”不适合“依赖旧值进行条件判断”的操作。后者必须用 CAS 循环。5.2 不要用它在多个字段之间建立一致性另一个常见误区是试图用多个Interlocked.Exchange分别更新多个相关字段来替代锁。例如Interlocked.Exchange(ref _name, name); Interlocked.Exchange(ref _age, age);假设代码不变量是“名字和年龄必须匹配”那这两次交换之间就不存在原子性。另一个线程可能在第一次交换后、第二次交换前读取到新名字配旧年龄从而看到不一致的状态。想让多个字段整体更新只有两种方案一是把字段封装进一个不可变对象用单个引用交换二是退回到lock。在业务并发场景前者通常是更好的设计——用不可变对象 单个引用交换来达到“多字段一致性”。5.3 Exchange 不是银弹优先考虑简单方案我见过不少团队为了秀技巧把一个简单计数器搞成 SpinLock Interlocked 的组合最后性能没上去可读性先崩了。实际上.NET 已经为你准备好了很多并发容器ConcurrentDictionary、ConcurrentQueue、BlockingCollection等它们内部已经用原子操作优化过。如果你的需求能直接用这些集合表达就不要自己造轮子。Interlocked.Exchange真正的用武之地是那些“既不想引锁、又想实现极简同步信号”的场景比如状态标志、单元素缓冲、无锁队列的头尾指针、自旋锁内部实现等。用之前先问自己一句这个操作是不是真的只需要一行如果答案是两三行那大概率应该用lock或更高层的并发原语。5.4 性能实测什么情况下值得用 Exchange我做过一组对比测试8 个线程同时对一个int执行 100 万次递增。普通counter在无同步时最终结果错误且耗时约 50ms用lock包裹counter耗时大约 900ms用Interlocked.Increment耗时大约 280ms。可见原子操作在简单计数场景下比锁快 3 倍以上。但换成更复杂的临界区比如要执行一段几十行的逻辑里面还有条件分支和异常处理此时直接用Interlocked根本不可行必须用lock。所以性能对比不能只看单次算得快不快还要看场景匹配度。我在实际项目中会先写逻辑简单、依赖少、可比较的Interlocked操作如果后面临界区复杂了再改成lock两边代码都好维护。5.5 调试与测试原子操作不一定更好排查原子操作保障了正确性却没有提供“锁”这种明确的获取/释放边界所以调试起来有时候比锁更难。比如你不小心写了一个死循环自旋Debugger 挂上去时很难分清线程是卡在竞争还是真的死锁。我的经验是所有用了Interlocked的地方都要写清楚它是保护哪个共享变量的、不变的规则是什么最好在代码注释里画出预期的状态流转。无锁代码对可读性的要求更高缺了注释三个月后连你自己都看不懂。6. 从 Exchange 到 CAS进一步扩展无锁技能树6.1 CompareExchange 与 Exchange 的配合Interlocked.Exchange和Interlocked.CompareExchange是互补关系前者是无条件交换后者是带条件的交换。用Exchange的地方往往能用CompareExchange替代但反过来不行。在实际设计中常见组合是用Exchange快速“抢占”某个标志比如自旋锁获取锁。用CompareExchange实现“乐观式”更新比如无锁栈的 Push 操作public void Push(Node node) { while (true) { Node head _head; node.Next head; if (Interlocked.CompareExchange(ref _head, node, head) head) break; } }这里CompareExchange会在Head没变时把新节点作为头节点如果变了就重试。它依赖的是“读取-比较-写入”三个动作绑定成一条指令。理解了这些你会发现Exchange更像一把直来直去的枪而CompareExchange是一把带瞄准镜的狙击枪。它们属于同一套底层机制只是应用层次不同。6.2 从 Exchange 到 Volatile 的关系Interlocked.Exchange和Volatile.Write都能实现“带内存屏障的写入”但语义有区别。Interlocked.Exchange的原子性更强还返回旧值Volatile.Write通常只保证写顺序不保证原子读改写。如果只需要“把值安全地写出去不需要旧值”Volatile.Write可能更合适但如果你希望同一句代码里拿到旧值那Exchange无可替代。我在个人项目里经常用Exchange做“一次性令牌”private int _token; public int TakeToken() { return Interlocked.Exchange(ref _token, 0); }取令牌和清令牌一步搞定不会出现两个线程同时拿到同一个令牌的情况。换成Volatile.Read加Volatile.Write两句话中间就会有空隙反而更容易出问题。所以选择哪个原语关键还是看你对返回值是否有依赖。6.3 注意事项清单结合我自己的经验整理一个实用清单写Interlocked.Exchange前过一遍确认传入字段是ref形式不要传属性。属性编译后是 get/set 方法无法获取存储位置无法用ref传递所以必须使用字段。不要对readonly字段使用因为Exchange要改写字段值。字段不要声明成 volatile反过来会混淆语义直接用Interlocked方法就够了加 volatile 并不能提供原子交换。泛型重载Interlocked.ExchangeT仅适用于引用类型如果泛型参数是结构体会编译失败。在循环内使用Exchange自旋时要加入SpinWait或Thread.Yield避免空转浪费 CPU。32 位平台下对long字段的原子操作要特别注意对齐问题好在 .NET 提供的重载已经处理好了平台差异。7. 完整的可运行示例一个线程安全的“资源发放器”最后分享一个相对完整的小示例把Interlocked.Exchange和CompareExchange结合起来展示它们在真实场景中的力量。假设我有一个资源池里面有固定数量的资源需求是多个线程并发地申请一个资源拿到后返回资源 ID用完再释放资源不可重复发放。public class ResourceAllocator { private readonly int _capacity; private int _nextId; private readonly bool[] _used; private readonly object _lock new object(); public ResourceAllocator(int capacity) { _capacity capacity; _used new bool[capacity]; _nextId 0; } public int Allocate() { while (true) { int candidate _nextId; if (candidate _capacity) return -1; // 无可用资源 // 用 CAS 把 _nextId 加 1同时防止多人拿到同一个 candidate int next candidate 1; if (Interlocked.CompareExchange(ref _nextId, next, candidate) candidate) { // 成功获得 candidate检查是否可用 lock (_lock) { if (_used[candidate]) continue; // 已经被用了外层循环重新取 _used[candidate] true; return candidate; } } // 说明 _nextId 已被别的线程更新循环重试 } } public void Release(int id) { lock (_lock) { _used[id] false; } } }这里我故意混合了CompareExchange和lockCompareExchange用来并发安全地递增游标保证每个线程拿到的 candidate 不重复内部用 lock 来保护_used数组的标记和释放因为数组的读写和判断是两个动作无法用单个原子操作完成。这种“原子操作做快速路径 锁做慢速路径”的组合在很多高性能代码里是常见套路。如果你想把_used也变成无锁可以用Interlocked.Exchange(ref _used[id], true)把 bool 改成 int但那样代码会变得更绕除非能测出显著性能提升否则不建议。我个人的经验是无锁代码多一行复杂度就要多一份可读性成本能不用就不用。再来看一个纯Exchange的场景日志开关。private int _logEnabled 1; public void EnableLog(bool enabled) { Interlocked.Exchange(ref _logEnabled, enabled ? 1 : 0); } public void WriteLog(string message) { if (Volatile.Read(ref _logEnabled) 1) Console.WriteLine(message); }日志开关这种高频读取、极少写入的场景用Interlocked.Exchange更新标志位再合适不过了。它不需要锁也不需要搞复杂的内存屏障只需要在写的时候原子替换在读的时候用Volatile.Read拿最新值。很多项目里会看到类似的开关设计比用volatile bool更规范因为volatile bool在 .NET 中并不保证所有平台上都有原子性而Interlocked有明确定义的语义。8. 结尾一段来自实践的反思回头再看Interlocked.Exchange它其实教会我一件事并发问题的本质不是“加锁”和“不加锁”的二选一而是“如何在最小范围内用最合适的原语保证数据的一致性”。Exchange把“拿旧值、放新值”这个动作在硬件层面焊接成一体让我在写无锁代码时能少考虑一步时序问题。但它的能力边界也很清楚——它只解决单变量交换不解决多变量一致性更不解决业务上的复合条件判断。我个人在实际项目中总结出的经验是使用Interlocked.Exchange前先在注释里回答三个问题——这个变量会被哪些线程写读到的旧值用来做什么如果写操作发生重排会不会破坏不变式回答完这三个问题你会发现一半情况下你其实不需要它另一半情况下你会非常确定它就是最优解。多线程编程最怕的不是慢而是“看起来对但不知道为什么会错”。把每个原语的边界揉碎了想清楚你的代码才算真正站在了地基上。
