假设一个类有一个被多个线程访问的 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++;
只要您记住在访问this.counter的任何其他位置上都要lock，这样做是安全的。 它可以防止任何其他线程执行由locker保护的任何其他代码。
使用锁还可以防止上述多CPU重排问题，这非常好。
问题在于，锁定很慢，如果您在与其不相关的其他位置上重新使用locker，则可能会无缘无故地阻塞其他线程。
Interlocked.Increment(ref this.counter);
这是安全的，因为它实际上在“一次命中”中执行读取、增加和写入操作，不能被中断。由于这个原因，它不会影响任何其他代码，您也不需要记住在其他地方锁定。它也非常快（如MSDN所说，在现代CPU上，这通常只是一个CPU指令）。
然而，我并不确定它是否可以避免其他CPU重新排序，或者是否还需要将volatile与增量结合使用。
Interlocked注意事项：
既然volatile不能解决这些类型的多线程问题，那么它有什么用呢？一个很好的例子是你有两个线程，一个总是写入一个变量（比如queueLength），一个总是从同一变量中读取。
如果queueLength不是易失的，线程A可能会写入五次，但线程B可能会看到这些写入被延迟（甚至可能在错误的顺序中）。
一个解决方案是加锁，但你也可以在这种情况下使用易失。这将确保线程B始终能看到线程A写入的最新内容。然而需要注意的是，仅当你具有从未读取的写入者和从未写入的读取者以及正在写入的内容是原子值时，才能使用此逻辑。一旦进行单个读取修改写入操作，就需要使用交错操作或锁定。
编辑:如评论中所述，现在我很高兴在仅涉及单个变量并且显然可行的情况下使用Interlocked。当它变得更加复杂时，我仍然会回归锁定...
在需要增加操作时，使用volatile无效-因为读取和写入是分开的指令。另一个线程可以在你读取但在你写回之前更改该值。
就个人而言，我几乎总是使用锁定-以一种明显正确的方式比使用易失性或Interlocked.Increment更容易掌握。我认为，无锁多线程编程是真正的线程专家才能做到的，而我不属于这个范畴。如果Joe Duffy和他的团队构建出不需要像我构建的那样多锁定的优秀库，那太棒了，我会毫不犹豫地使用它-但是当我自己进行线程处理时，我尽量保持简单。
"volatile"并不能替代Interlocked.Increment！它只是确保变量不会被缓存，而是直接使用。
增加一个变量需要实际上执行三个操作：
Interlocked.Increment将所有三个部分作为单个原子操作执行。
你需要的是锁定或互锁增量。
volatile 绝对不是你想要的 - 它只是告诉编译器即使当前代码路径允许编译器优化从内存读取，也要将变量视为始终在改变。
例如：
while (m_Var)
{ }
希望这能解决问题。
更多信息，请参见“了解低锁定技术在多线程应用程序中的影响” - http://msdn.microsoft.com/en-au/magazine/cc163715.aspx。
p.s. 什么促使我这么晚才回复？所有回复都在解释上明显不正确（特别是标记为答案的回复），我必须为任何阅读此文的人澄清一下。 耸肩
p.p.s. 我假设目标是 x86/x64 而不是 IA64（它有不同的内存模型）。请注意，微软的 ECMA 规范存在问题，它指定了最弱的内存模型而不是最强的一个（最好针对最强的内存模型进行规定，以便在各个平台上保持一致。否则，在 x86/x64 上运行24/7的代码可能在 IA64 上根本无法运行，尽管英特尔已为 IA64 实现了类似强大的内存模型）- 微软自己也承认了这一点 - http://blogs.msdn.com/b/cbrumme/archive/2003/05/17/51445.aspx。
Interlocked函数不会锁定。它们是原子操作，这意味着它们可以在增量期间完成而不可能发生上下文切换。因此不存在死锁或等待的可能性。
我认为你应该始终优先选择使用它来进行锁定和增量操作。
如果您需要在一个线程中进行写入并在另一个线程中进行读取，并且希望优化器不重新排列变量上的操作（因为在另一个线程中发生了一些优化器不知道的事情），那么Volatile就非常有用了。这是与如何增量选择无关的选择。
如果您想更多地了解无锁代码以及编写它的正确方法，那么这真的是一篇很好的文章。
lock(...)可以起作用，但可能会阻塞线程，并且如果其他代码以不兼容的方式使用相同的锁，可能会导致死锁。
Interlocked.*是正确的方法...现代CPU支持这种原语，因此开销要小得多。
仅使用volatile是不正确的。一个线程试图检索并写回修改后的值仍然可能与另一个执行相同操作的线程发生冲突。
我进行了一些测试，以查看理论如何实际运作：kennethxu.blogspot.com / 2009/05 / interlocked-vs-monitor-performance.html 。 我的测试更专注于CompareExchnage，但Increment的结果类似。在多CPU环境中，Interlocked不一定更快。这是在一个两年前的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
原子性、易失性和不可变性是不同的，第一部分 - (Eric Lippert的编程奇遇)
Sayonara Volatile - （Joe Duffy的Weblog于2012年的Wayback Machine快照）
volatile、Interlocked和lock之间的区别：
sbyte、byte、short、ushort、int、uint、char、float和bool。byte、sbyte、short、ushort、int或uint之一。IntPtr和UIntPtr。其他类型，包括double和long，不能被标记为"volatile"，因为对于这些类型的字段的读写不能保证是原子性的。为了保护对这些类型字段的多线程访问，使用Interlocked类成员或使用lock语句来保护访问。
我在这里只是想指出Orion Edwards答案中关于volatile的错误。
他说：
"如果它是volatile，这只是确保两个CPU同时看到相同的数据。"
这是错误的。在微软有关volatile的文档中提到：
"在多处理器系统上，volatile读操作不能保证获得任何处理器写入该内存位置的最新值。同样，volatile写操作不能保证所写入的值会立即对其他处理器可见。"