易失性，连锁性与锁定

假设一个类具有一个public int counter可由多个线程访问的字段。这int仅递增或递减。

要增加此字段，应使用哪种方法，为什么？

• lock(this.locker) this.counter++;，
• Interlocked.Increment(ref this.counter);，
• 将的访问修饰符更改counter为public volatile。

现在我已经发现volatile，我已经删除了许多lock语句和对的使用Interlocked。但是，有理由不这样做吗？

最差（实际上不会工作）

将的访问修饰符更改counter为public volatile

正如其他人所提到的那样，仅此一点实际上是不安全的。关键volatile是，在多个CPU上运行的多个线程可以并且将缓存数据并重新排序指令。

如果不是 volatile，并且CPU A递增一个值，则CPU B可能直到一段时间后才能真正看到该递增的值，这可能会引起问题。

如果为volatile，则仅确保两个CPU同时看到相同的数据。它根本不会阻止他们交错读取和写入操作，而这正是您要避免的问题。

次好的：

lock(this.locker) this.counter++;

这是安全的操作（只要您记得lock访问的其他地方this.counter）。它可以防止任何其他线程执行由保护的其他任何代码locker。同样，使用锁可以防止上述多CPU重新排序问题，这非常好。

问题是，锁定速度很慢，如果您locker在与实际无关的其他地方重复使用，则最终可能会无缘无故地阻塞其他线程。

最好

Interlocked.Increment(ref this.counter);

这是安全的，因为它可以有效地读取，递增和写入不会中断的“一次命中”。因此，它不会影响任何其他代码，并且您也不需要记住锁定其他任何位置。它也非常快（正如MSDN所说，在现代CPU上，这实际上是一条CPU指令）。

但是，我不确定是否会绕过其他CPU重新排序，或者是否还需要将volatile与增量结合起来。

连锁注意事项：

1. 互锁方法可同时在任意数量的内核或CPU上使用。
2. 互锁的方法在执行的指令周围加上了完整的围栏，因此不会发生重新排序。
3. 互锁方法不需要甚至不支持访问volatile字段，因为volatile在给定字段上的操作周围放置了半围墙，而联锁使用的是全围墙。

脚注：挥发物实际上是有益的。

由于volatile不能防止此类多线程问题，它的用途是什么？一个很好的例子是说您有两个线程，一个线程总是写一个变量（例如queueLength），而一个线程总是从同一个变量读取。

如果queueLength不是易失性的，线程A可能会写入五次，但是线程B可能会认为这些写入被延迟（甚至可能以错误的顺序）。

解决方案是锁定，但在这种情况下也可以使用volatile。这样可以确保线程B始终可以看到线程A编写的最新内容。但是请注意，只有当您有从未读过的作家和从未写过的读者，并且您要写的东西是原子值时，此逻辑才起作用。一旦完成一次读-修改-写操作，就需要进入互锁操作或使用锁定。

编辑：正如在评论中指出，这几天我很高兴地使用Interlocked了的情况下，单变量的地方是明显没关系。当变得更加复杂时，我仍然会恢复锁定状态。

volatile当您需要递增时，使用无助-因为读和写是分开的指令。读完之后但写回之前，另一个线程可能会更改该值。

就我个人而言，我几乎总是只是锁定-以明显正确的方式比波动或Interlocked.Increment 更容易正确。就我而言，无锁多线程是针对真正的线程专家的，我不是其中之一。如果Joe Duffy和他的团队构建了不错的库，这些库可以并行化事物而又没有我要构建的东西那么多，那真是太好了，我将在心跳中使用它-但是当我自己进行线程化时，我会尝试把事情简单化。

” volatile“不能代替Interlocked.Increment！它只是确保该变量不被缓存，而是直接使用。

递增变量实际上需要三个操作：

1. 读
2. 增量
3. 写

Interlocked.Increment 将这三个部分作为一个原子操作执行。

您正在寻找锁定或互锁增量。

可变性绝对不是您要追求的，它只是告诉编译器将变量视为始终更改，即使当前代码路径允许编译器以其他方式优化对内存的读取。

例如

while (m_Var)
{ }

如果在另一个线程中将m_Var设置为false，但未将其声明为volatile，则编译器可以通过检查CPU寄存器（例如EAX）自由地使其成为无限循环（但并不意味着总是如此）。而不是从一开始就读取m_Var的内容），而不是对m_Var的内存位置发出另一次读取（这可能是已缓存的-我们不知道也不在乎，这就是x86 / x64的缓存一致性的关键）。其他人先前提到指令重新排序的所有文章只是表明他们不了解x86 / x64体系结构。挥发性确实不发出读/写障碍，如先前帖子所言，“阻止重新排序”。实际上，再次感谢MESI协议，无论实际结果是退回物理内存还是仅驻留在本地CPU的缓存中，我们都可以确保在CPU中读取的结果始终相同。我不会太详细地介绍这个问题，但是请放心，如果出错，英特尔/ AMD可能会召回处理器！这也意味着我们不必担心乱序执行等问题。始终保证结果可以按顺序退役-否则我们将被塞满！

使用Interlocked Increment，处理器需要退出，从给定的地址中获取值，然后进行递增并写回-所有这些都拥有整个缓存行的独占所有权（锁定xadd），以确保没有其他处理器可以修改它的价值。

使用volatile，您仍然只会得到1条指令（假设JIT达到了应有的效率）-inc dword ptr [m_Var]。但是，处理器（cpuA）在执行互锁版本时不会要求获得缓存行的专有所有权。可以想象，这意味着其他处理器可以在cpuA读取m_Var之后将其写回m_Var。因此，您不必再增加两次该值，而只需结束一次即可。

希望这可以解决问题。

有关详细信息，请参阅“了解低锁定技术在多线程应用程序中的影响”-http: //msdn.microsoft.com/zh-cn/au-mag/magazine/cc163715.aspx

ps是什么促使这个很晚的答复？所有的答复在解释中都如此公然不正确（尤其是标记为答案的答复），我只需要为阅读此书的其他人清除它即可。耸耸肩

PPS我假设目标是x86 / x64而不是IA64（它具有不同的内存模型）。请注意，Microsoft的ECMA规范搞砸了，因为它指定了最弱的内存模型而不是最强的内存模型（始终最好针对最强的内存模型进行指定，以便在各个平台上保持一致-否则，代码将在x86 /上以24-7运行尽管Intel已经为IA64实现了类似的强大内存模型，但x64可能根本无法在IA64上运行）-微软自己承认了这一点-http: //blogs.msdn.com/b/cbrumme/archive/2003/05/17/51445.aspx。

互锁的功能不会锁定。它们是原子的，这意味着它们可以完成而不会在增量期间进行上下文切换。因此，没有死锁或等待的机会。

我要说的是，您应该始终喜欢锁定和递增。

如果您需要在一个线程中进行写入以在另一个线程中进行读取，并且如果您希望优化程序不对变量进行重新排序（因为在优化程序不知道的另一线程中发生了事情），则Volatile很有用。这是增加方式的正交选择。

如果您想了解有关无锁代码的更多信息以及正确的编写方式，这是一篇非常不错的文章。

http://www.ddj.com/hpc-high-performance-computing/210604448

lock（...）可以工作，但是可能会阻塞线程，并且如果其他代码以不兼容的方式使用相同的锁，则可能导致死锁。

Interlocked。*是执行此操作的正确方法...开销要少得多，因为现代CPU支持将此作为原始函数。

单靠挥发是不正确的。试图检索然后写回修改后值的线程仍可能与另一个执行此操作的线程冲突。

我做了一些测试以了解该理论的实际工作原理：kennethxu.blogspot.com/2009/05/interlocked-vs-monitor-performance.html。我的测试更侧重于CompareExchnage，但Increment的结果却相似。在多CP​​U环境中，互锁不是必须更快。这是在2年历史的16 CPU服务器上Increment的测试结果。切记测试还涉及增加后的安全读取，这在现实世界中是典型的。

D:\>InterlockVsMonitor.exe 16
Using 16 threads:
          InterlockAtomic.RunIncrement         (ns):   8355 Average,   8302 Minimal,   8409 Maxmial
    MonitorVolatileAtomic.RunIncrement         (ns):   7077 Average,   6843 Minimal,   7243 Maxmial

D:\>InterlockVsMonitor.exe 4
Using 4 threads:
          InterlockAtomic.RunIncrement         (ns):   4319 Average,   4319 Minimal,   4321 Maxmial
    MonitorVolatileAtomic.RunIncrement         (ns):    933 Average,    802 Minimal,   1018 Maxmial

我第二次回答乔恩·斯基特（Jon Skeet）的问题，并希望为每个想更多地了解“易失性”和“互锁”的人添加以下链接：

原子性，波动性和不变性是不同的，第一部分-（埃里克·利珀特的《编码奇妙历险记》）

原子性，波动性和不变性是不同的，第二部分

原子性，波动性和不变性是不同的，第三部分

Sayonara Volatile-（乔伊·达菲的Weblog的Wayback Machine快照在2012年出现）

我想添加到其他的答案之间的区别提到的volatile，Interlocked和lock：

volatile关键字可以应用于以下类型的字段：

• 参考类型。
• 指针类型（在不安全的上下文中）。请注意，尽管指针本身可以是易失性的，但其指向的对象却不能。换句话说，您不能将“指针”声明为“易失性”。
• 简单的类型，如sbyte，byte，short，ushort，int，uint，char，float，和bool。
• 枚举类型具有以下基本类型之一：byte，sbyte，short，USHORT， int，或uint。
• 通用类型参数已知为引用类型。
• IntPtr和UIntPtr。

不能将其他类型（包括double和）long标记为“易失性”，因为不能保证对这些类型的字段进行读写操作。要保护对这些类型的字段的多线程访问，请使用Interlocked类成员或使用该lock语句保护访问 。