.NET 中双重检查锁定中需要 volatile 修饰符

Question

多篇文章指出，在 .NET 中实现双重检查锁定时，您要锁定的字段应该应用 volatile 修饰符。但到底为什么呢？考虑以下示例：

public sealed class Singleton
{
   private static volatile Singleton instance;
   private static object syncRoot = new Object();

   private Singleton() {}

   public static Singleton Instance
   {
      get 
      {
         if (instance == null) 
         {
            lock (syncRoot) 
            {
               if (instance == null) 
                  instance = new Singleton();
            }
         }

         return instance;
      }
   }
}

为什么“lock (syncRoot)”没有实现必要的内存一致性？在“lock”语句之后，读和写都是易失性的，因此可以实现必要的一致性，这不是真的吗？

Answer 1

挥发性是不必要的。嗯，某种**

易失性 用于在变量的读取和写入之间创建内存屏障*。
lock 使用时，除了限制一个线程对该块的访问外，还会导致在 lock 内的块周围创建内存屏障。
内存屏障使得每个线程读取变量的最新值（而不是缓存在某些寄存器中的本地值），并且编译器不会重新排序语句。使用易失性是不必要的**，因为你已经获得了锁。

Joseph Albahari 比我更好地解释了这些东西。

请务必查看 Jon Skeet 的在 C# 中实现单例的指南

更新：
*易失性 导致变量读取为 VolatileRead 并写入为 VolatileWrite，这在 CLR 上的 x86 和 x64 上通过以下方式实现一个MemoryBarrier。它们在其他系统上可能更细粒度。

**仅当您在 x86 和 x64 处理器上使用 CLR 时，我的答案才是正确的。在其他内存模型中可能也是如此，例如 Mono（和其他实现）、Itanium64 和未来的硬件。这就是乔恩在他的文章中提到的双重检查锁定的“陷阱”。

可能需要执行{将变量标记为易失性、使用Thread.VolatileRead读取变量或插入对Thread.MemoryBarrier的调用}之一使代码在弱内存模型情况下正常工作。

据我了解，在 CLR 上（甚至在 IA64 上），写入永远不会重新排序（写入始终具有释放语义）。但是，在 IA64 上，读取可能会重新排序为先于写入，除非它们被标记为易失性。不幸的是，我无法访问 IA64 硬件来玩，所以我所说的任何内容都只是猜测。

我还发现这些文章很有帮助：
http://www.codeproject.com/KB/tips/MemoryBarrier.aspx
万斯·莫里森的文章（所有内容都链接到此，它讨论了双重检查锁定）
chris brumme 的文章（所有内容都链接到此）< br>
Joe Duffy：双重检查锁定的损坏变体

luis abreu 的多线程系列也很好地概述了这些概念
http://msmvps。 com/blogs/luisabreu/archive/2009/06/29/multithreading-load-and-store-reordering.aspx
http://msmvps.com/博客/luisabreu/archive/2009/07/03/multithreading-introducing-memory-fences.aspx

Answer 2

有一种方法可以在没有 volatile 字段的情况下实现它。我会解释一下......

我认为锁内的内存访问重新排序是危险的，这样您就可以在锁外获得未完全初始化的实例。为了避免这种情况，我这样做：

public sealed class Singleton
{
   private static Singleton instance;
   private static object syncRoot = new Object();

   private Singleton() {}

   public static Singleton Instance
   {
      get 
      {
         // very fast test, without implicit memory barriers or locks
         if (instance == null)
         {
            lock (syncRoot)
            {
               if (instance == null)
               {
                    var temp = new Singleton();

                    // ensures that the instance is well initialized,
                    // and only then, it assigns the static variable.
                    System.Threading.Thread.MemoryBarrier();
                    instance = temp;
               }
            }
         }

         return instance;
      }
   }
}

理解代码

想象一下，Singleton 类的构造函数中有一些初始化代码。如果在使用新对象的地址设置字段后对这些指令重新排序，那么您将得到一个不完整的实例...想象一下该类具有以下代码：

private int _value;
public int Value { get { return this._value; } }

private Singleton()
{
    this._value = 1;
}

现在想象一下使用 new 运算符调用构造函数：

instance = new Singleton();

这可以是扩展到这些操作：

ptr = allocate memory for Singleton;
set ptr._value to 1;
set Singleton.instance to ptr;

如果我像这样重新排序这些指令会怎样：

ptr = allocate memory for Singleton;
set Singleton.instance to ptr;
set ptr._value to 1;

这有什么不同吗？如果您想到单个线程，则否。 是如果你想到多个线程...如果线程在将实例设置为ptr之后被中断怎么办：

ptr = allocate memory for Singleton;
set Singleton.instance to ptr;
-- thread interruped here, this can happen inside a lock --
set ptr._value to 1; -- Singleton.instance is not completelly initialized

这就是内存屏障通过不允许内存访问来避免的事情重新排序：

ptr = allocate memory for Singleton;
set temp to ptr; // temp is a local variable (that is important)
set ptr._value to 1;
-- memory barrier... cannot reorder writes after this point, or reads before it --
-- Singleton.instance is still null --
set Singleton.instance to temp;

快乐编码！

Answer 3

您应该将 volatile 与双重检查锁定模式一起使用。

大多数人都将这篇文章作为你不需要 volatile 的证据：
https://msdn.microsoft.com/en-us/magazine/ cc163715.aspx#S10

但他们未能读到最后：
“最后的警告 - 我只是根据现有处理器上观察到的行为来猜测 x86 内存模型。因此，低锁技术也很脆弱，因为随着时间的推移，硬件和编译器可能会变得更加激进。以下是一些策略首先，尽可能避免低锁技术。最后，尽可能采用最弱的内存模型，使用易失性声明而不是依赖隐式保证。”

如果您需要更有说服力，请阅读这篇有关 ECMA 规范将用于其他平台的文章：
msdn.microsoft.com/en-us/magazine/jj863136.aspx

如果您需要进一步说服，请阅读这篇较新的文章，其中可能会进行优化，以防止它在没有易失性的情况下工作：
msdn.microsoft.com/en-us/magazine/jj883956.aspx

总之，它“可能”暂时为您工作而无需 volatile，但不要冒险它编写正确的代码并使用 volatile 或 volatileread/write 方法。建议采取其他措施的文章有时会忽略 JIT/编译器优化的一些可能的风险，这些风险可能会影响您的代码，以及我们未来可能发生的可能破坏您的代码的优化。另外，正如上一篇文章中提到的假设，之前在没有 易失性的情况下工作的假设可能在 ARM 上不成立。

更多信息请访问：https://essentialsoftwaredevelopment.com

Answer 4

我认为没有人真正回答过这个问题，所以我会尝试一下。

易失性和第一个 if (instance == null) 不是“必需的”。锁将使这段代码成为线程安全的。

所以问题是：为什么要添加第一个 if (instance == null)？

原因大概是为了避免不必要地执行锁定的代码部分。当您在锁内执行代码时，任何其他尝试执行该代码的线程都会被阻止，如果您尝试从多个线程频繁访问单例，这会减慢您的程序速度。根据语言/平台的不同，锁本身也可能会产生您希望避免的开销。

因此，添加第一个空检查是一种非常快速的方法来查看是否需要锁。如果不需要创建单例，则可以完全避免锁。

但是，如果不以某种方式锁定引用，则无法检查引用是否为空，因为由于处理器缓存，另一个线程可能会更改它，并且您将读取“过时”值，这将导致您不必要地输入锁。但你正试图避免锁定！

因此，您可以将单例设置为易失性，以确保您读取最新值，而无需使用锁。

您仍然需要内部锁，因为 volatile 仅在对变量的单次访问期间保护您 - 如果不使用锁，您无法安全地测试和设置它。

现在，这真的有用吗？

好吧，我会说“在大多数情况下，不”。

如果 Singleton.Instance 可能因锁而导致效率低下，那么为什么要如此频繁地调用它以至于这会成为一个严重的问题？单例的要点在于只有一个，因此您的代码可以读取并缓存单例引用一次。

我能想到的唯一无法进行缓存的情况是当您有大量线程时（例如，使用新线程来处理每个请求的服务器可能会创建数百万个运行时间非常短的线程，每个线程这必须调用 Singleton.Instance 一次）。

因此，我怀疑双重检查锁定是一种在非常具体的性能关键案例中占有一席之地的机制，然后每个人都攀上了“这是正确的做法”的潮流，而没有真正考虑它的作用以及它是否有效在他们使用它的情况下实际上是必要的。

Answer 5

AFAIK（并且 - 谨慎对待这一点，我没有做很多并发的事情）不。锁只是为您提供多个竞争者（线程）之间的同步。

另一方面，易失性告诉您的机器每次都重新评估该值，这样您就不会偶然发现缓存的（错误的）值。

请参阅 http://msdn.microsoft.com/en-us/library/ms998558 .aspx 并注意以下引用：

此外，该变量被声明为易失性，以确保在访问实例变量之前完成对实例变量的赋值。

易失性的说明： http://msdn.microsoft .com/en-us/library/x13ttww7%28VS.71%29.aspx

Answer 6

锁就足够了。 MS 语言规范 (3.0) 本身在第 8.12 节中提到了这种确切的场景，但没有提及 易失性：

更好的方法是同步
通过锁定来访问静态数据
私有静态对象。例如：

类缓存
{
    私有静态对象synchronizationObject = new object();
    公共静态无效添加（对象x）{
        锁 (Cache.synchronizationObject) {
          ...
        }
    }
    公共静态无效删除（对象x）{
        锁 (Cache.synchronizationObject) {
          ...
        }
    }
}

Answer 7

我想我已经找到了我正在寻找的东西。详细信息请参阅本文 - http://msdn.microsoft.com/ en-us/magazine/cc163715.aspx#S10。

综上所述 - 在 .NET 中，在这种情况下确实不需要 volatile 修饰符。然而，在较弱的内存模型中，在延迟启动对象的构造函数中进行的写入可能会在写入字段后延迟，因此其他线程可能会在第一个 if 语句中读取损坏的非空实例。

Answer 8

这是一篇关于使用 volatile 和双重检查锁定的非常好的文章：

http: //tech.puredanger.com/2007/06/15/double-checked-locking/

在 Java 中，如果目标是保护变量，则无需锁定（如果它被标记为 volatile）