1. 为什么我们需要重新认识Interlocked多线程编程里最让人头疼的问题之一就是多个线程同时读写同一个变量时产生的竞态条件。很多人第一反应是用lock把代码块包起来简单粗暴也确实有效。但lock本质上是一把重量级的互斥锁涉及到内核对象、线程上下文切换开销并不小。如果你的共享状态只是一个整数计数器用lock就有点像用大炮打蚊子。Interlocked这个静态类就是为这种场景而生的。它位于System.Threading命名空间下提供了一系列原子操作能在不使用锁的前提下保证对单个变量的读-改-写是原子的。我第一次认真研究它是因为一个高并发日志统计模块在压测时数据总是对不上排查了半天发现是count在多个线程下丢了更新。换成Interlocked.Increment之后问题立刻消失性能还比加锁方案好了不少。这篇文章会从实际使用角度出发把Interlocked的核心方法、底层原理、适用场景、容易踩的坑都讲清楚。不管你是刚接触多线程的新手还是已经用过但没深究的老手应该都能从中找到有用的东西。文章里的代码示例都是可以直接跑的建议边看边在本地验证。2. Interlocked的核心方法族与底层逻辑2.1 它到底解决了什么问题先看一个最经典的例子。假设我们有一个计数器多个线程同时给它加一private int _counter 0; public void Increment() { _counter; }这行_counter看起来是一条语句但在IL层面它被拆成了三步读取_counter的值到寄存器寄存器值加一把结果写回_counter。三个线程如果同时执行到第一步都读到了相同的值那么最终写回去的结果只会比原来大1而不是大3。这就是丢失更新。Interlocked.Increment(ref _counter)把这三步合并成了一个不可分割的原子操作。CPU层面通过总线锁或缓存锁来保证同一时刻只有一个核心能操作这块内存其他核心的访问会被阻塞到操作完成。这个机制不需要线程进入内核态等待所以开销远小于lock。2.2 常用方法一览Interlocked类提供的方法不算多但每一个都有明确的用途。下面这张表把最常用的几个列出来方便你快速查阅方法作用典型场景Increment(ref int)原子加1计数器、统计Decrement(ref int)原子减1信号量模拟、倒计数Add(ref int, int)原子加指定值累加求和Exchange(ref T, T)原子替换并返回旧值状态切换、交换引用CompareExchange(ref T, T, T)比较相等则替换无锁算法、懒初始化Read(ref long)原子读取64位值32位系统上读long其中CompareExchange是最强大的一个它是实现各种无锁数据结构和模式的基础。它的签名是CompareExchange(ref T location, T value, T comparand)语义是如果location当前等于comparand就把value写进去无论是否替换都返回location的原始值。这个“比较-替换”的组合在硬件层面是一条指令x86上是CMPXCHG所以是原子的。2.3 泛型重载与引用类型的原子操作从.NET 2.0开始Interlocked就有了泛型版本CompareExchangeT和ExchangeT其中T必须是引用类型。这意味着你可以对对象引用做原子替换这在实现无锁栈、无锁队列时非常有用。private Node _head; public void Push(int value) { Node newNode new Node(value); Node oldHead; do { oldHead _head; newNode.Next oldHead; } while (Interlocked.CompareExchange(ref _head, newNode, oldHead) ! oldHead); }这段代码是一个无锁栈的入栈操作。它先记下当前头节点把新节点的Next指向它然后尝试用CAS把head替换成新节点。如果在这期间有其他线程改了headCAS会失败循环重试。整个过程没有任何锁在高并发下表现相当好。注意泛型版本的CompareExchange只支持引用类型值类型需要用对应的具体重载如CompareExchange(ref int, int, int)。如果你试图对自定义结构体使用泛型版本编译器会直接报错。3. 实操中必须掌握的几种典型模式3.1 线程安全计数器这是最基础也最常用的场景。比如你要统计某个接口的调用次数public class Metrics { private long _requestCount; private long _errorCount; public void RecordRequest() Interlocked.Increment(ref _requestCount); public void RecordError() Interlocked.Increment(ref _errorCount); public long RequestCount Interlocked.Read(ref _requestCount); public long ErrorCount Interlocked.Read(ref _errorCount); }这里用long而不是int是因为Interlocked.Read(ref long)能保证在32位系统上读取64位值的原子性。在32位平台上一个long的读写可能被拆成两次32位操作如果不加保护可能读到一个“半新半旧”的值。Interlocked.Read解决了这个问题。虽然现在64位系统是主流但如果你写的库需要兼容32位环境这个细节不能忽略。3.2 用CompareExchange实现懒初始化单例模式或者缓存场景中我们经常需要“只初始化一次”。用lock当然可以但CompareExchange能做得更轻量private SomeService _service; private readonly object _syncRoot new object(); public SomeService GetService() { if (_service null) { var newService new SomeService(); Interlocked.CompareExchange(ref _service, newService, null); } return _service; }这段代码的逻辑是如果_service为null就创建一个新的然后尝试用CAS把它写进去。如果另一个线程抢先写入了CAS会失败但没关系因为_service已经有值了直接返回即可。注意这里可能创建了多个SomeService实例但最终只有一个会被发布出去其他的会被垃圾回收。如果构造函数有副作用比如打开文件句柄这种写法就不合适了需要改用LazyT。3.3 原子状态机切换有时候我们需要根据当前状态决定是否执行某个操作比如“只有处于Running状态时才允许切换到Stopped”private int _state 0; // 0Idle, 1Running, 2Stopped public bool TryStop() { return Interlocked.CompareExchange(ref _state, 2, 1) 1; }CompareExchange返回的是原始值。如果原始值是1Running说明替换成功返回true否则返回false表示当前状态不允许停止。这种模式在实现有限状态机时非常简洁而且天然线程安全。3.4 无锁累加与Exchange的妙用Exchange方法在某些场景下能替代CompareExchange让代码更简洁。比如你要实现一个“重置计数器并返回旧值”的操作public long ResetAndGet() { return Interlocked.Exchange(ref _counter, 0); }这一行代码完成了两件事把_counter设为0同时返回它之前的值。如果用lock写至少需要三行。Exchange的原子性保证了这两个动作之间不会有其他线程插入。4. 那些年我踩过的坑与排查实录4.1 以为Interlocked能保护一切这是新手最容易犯的错误。Interlocked只能保证单个变量的操作是原子的它不能保护多个变量之间的一致性。比如下面这段代码Interlocked.Increment(ref _count); Interlocked.Add(ref _total, value);这两行各自是原子的但合在一起不是。在两个操作之间其他线程可能看到_count已经加了但_total还没加的状态。如果你的业务逻辑要求这两个变量必须同步更新那就必须用lock把两行包起来或者重新设计数据结构把两个值合并成一个不可分割的单元。4.2 在属性上使用InterlockedC#的属性本质上是方法你不能把属性传给ref参数。下面这种写法编译不过public int Count { get; set; } Interlocked.Increment(ref Count); // 编译错误解决办法是用字段代替属性或者写一个显式的方法private int _count; public int Count _count; public void IncrementCount() Interlocked.Increment(ref _count);4.3 忽略内存屏障的影响Interlocked的所有方法都隐含了完整的内存屏障这意味着操作前后的读写不会被CPU或编译器重排序。但如果你混用普通读写和Interlocked操作就可能出问题。看这个例子private int _data; private int _ready; public void Write() { _data 42; Interlocked.Exchange(ref _ready, 1); } public void Read() { if (Interlocked.CompareExchange(ref _ready, 0, 0) 1) { Console.WriteLine(_data); // 一定输出42吗 } }答案是肯定的。因为Interlocked.Exchange在写入_ready之前会插入一个释放屏障保证_data 42对其它核心可见。而CompareExchange在读取_ready时会插入获取屏障保证后续读取_data能看到之前写入的值。但如果你把Interlocked.CompareExchange换成普通的if (_ready 1)就不能保证了因为普通读取没有屏障语义。4.4 常见问题速查表现象可能原因解决思路计数器偶尔少加用了count而非Interlocked.Increment替换为原子操作CAS循环一直不成功ABA问题或竞争过于激烈引入版本号或改用锁32位系统上long值异常未使用Interlocked.Read统一用Interlocked.Read读取属性无法传ref属性不是变量改用字段或封装方法多变量不一致Interlocked只保护单变量合并变量或用lock关于ABA问题假设线程1读到值A线程2把值改成B又改回A线程1的CAS会误以为没人改过。解决办法是给值附加一个版本号每次修改版本号递增这样即使值相同版本号也不同CAS会正确失败。Interlocked本身不提供版本号机制需要自己实现。5. 性能对比与选型建议5.1 Interlocked vs lock vs 普通操作我做过一组简单的基准测试在8核机器上开8个线程每个线程对一个共享计数器累加1000万次方案耗时毫秒最终值是否正确普通count约30否严重丢失lock约1200是Interlocked.Increment约150是可以看到Interlocked比lock快了将近8倍而且结果正确。普通操作虽然最快但结果是错的没有参考价值。这个差距在高竞争场景下会更明显因为lock会导致线程频繁进出内核态。5.2 什么时候该用Interlocked什么时候不该用Interlocked适合的场景单个整数或引用的原子读写改、简单的计数器、状态标志切换、无锁数据结构的基础构件。不适合的场景需要保护多个变量的一致性、临界区内有复杂逻辑比如IO操作、需要等待条件成立应该用Monitor.Wait或SemaphoreSlim、竞争极其激烈导致CAS循环开销超过锁的开销。一个经验法则如果你的临界区只有一两行代码且只操作一个变量优先考虑Interlocked如果临界区超过五行或者涉及多个变量用lock更稳妥。不要为了追求“无锁”而把代码写得极其复杂可维护性也是重要的考量。5.3 关于SpinWait的配合使用在CAS循环中如果竞争激烈不断重试会浪费CPU。这时候可以配合SpinWaitSpinWait spin new SpinWait(); while (true) { int current _value; if (Interlocked.CompareExchange(ref _value, current 1, current) current) break; spin.SpinOnce(); }SpinWait会根据重试次数动态调整策略前期自旋后期让出时间片。这在实现自定义无锁结构时很有用但日常业务代码中很少需要手写这种循环。6. 从Interlocked延伸出去的知识点6.1 与volatile的区别很多人搞不清Interlocked和volatile的关系。简单说volatile只保证可见性和禁止重排序但不保证原子性。volatile int x; x仍然不是线程安全的。Interlocked既保证原子性又隐含内存屏障。所以如果你需要原子性用Interlocked如果只是需要一个线程写、另一个线程读的标志位volatile就够了。6.2 在异步代码中的注意事项async/await环境下代码可能在不同线程上恢复执行。如果你在异步方法里用Interlocked操作一个字段要确保这个字段不是线程亲和的比如不能是ThreadStatic。另外Interlocked不能跨await保持原子性因为await会释放线程中间可能有其他线程介入。如果需要在异步流程中保护共享状态应该用SemaphoreSlim而不是Interlocked。6.3 64位与32位的差异在64位系统上对long和double的读写本身就是原子的前提是正确对齐所以Interlocked.Read在64位下其实就是普通读取加一个屏障。但在32位系统上64位值的读写会被拆成两次必须用Interlocked.Read。如果你写的代码只在64位环境运行可以不用太担心这个但库开发者需要兼容两种情况。我在实际项目中的体会是Interlocked用好了能显著提升并发性能但它不是银弹。每次使用前都要问自己我保护的真的只是一个变量吗操作之间有没有依赖关系竞争激烈时CAS循环会不会成为瓶颈想清楚这些问题才能写出既快又对的并发代码。
