C# 中什么时候应该使用 volatile 关键字？

Question

任何人都可以对 volatile< 提供一个很好的解释C# 中的 /code>关键字？ 它解决了哪些问题，没有解决哪些问题？ 在什么情况下它可以让我不用使用锁定？

Answer 1

来自文档：

在多处理器系统上，易失性读取操作不能保证获得任何处理器写入该内存位置的最新值。

对我来说，这听起来像其他一些答案所说的那样，您不能保证“获得最新的价值”。 来自规范< /a>，唯一的保证似乎是：

volatile int v;

x = 5;
print(y);
...
v = 3; // previous read/write operations on this thread cannot be moved after this (even if there are no dependencies)

...

print(v); // following read/write operations on this thread cannot be moved before this (even if there are no dependencies)
x = 5;
print(y);
...

随心所欲。 例如，这意味着如果线程 1 执行多次易失性写入：

// thread 1
v1 = 1
...
v2 = 2

那么线程 2 将保证看到 v1 设置为 1，然后 v2被设置为2。 但例如不能保证线程间顺序。 Albahari 中的示例：

// thread 1
volatile int v1 = 0;
v1 = 1;
print(v2)

// thread 2
volatile int v2 = 0;
v2 = 1;
print(v1);

您可能会看到：

0
0

打印，因为读取可以移动到写道。

该规范也没有提及任何有关缓存的内容。 但是文档确实在注释中提及：

易失性读取和写入可确保将值读取或写入内存而不是缓存（例如，在处理器寄存器中）。

如果为真，则意味着您可以使用它们在线程之间进行同步，如下所示：

// main thread
v = false // at t = 0s

// worker thread 1
...
// value is written directly to memory
v = true // at t = 1s
...

// worker thread 2
...
// latest value from memory is retrieved
if (v)
{
  print("this is guaranteed to be printed after t = 1s")
}
...

这似乎与之前的说明相矛盾，即您不能假设您正在获取最新值。

IMO 似乎最好在日常编程中避免 易失性 ，并且仅在其特定的弱需求提供一些性能优化而不是更强大的同步机制（如锁）的情况下才谨慎使用它。

Answer 2

综上所述，问题的正确答案是：
如果您的代码在 2.0 运行时或更高版本中运行，则几乎从不需要 volatile 关键字，如果不必要地使用，则弊大于利。 IE 永远不要使用它。 但在运行时的早期版本中，需要对静态字段进行正确的双重检查锁定。 特别是其类具有静态类初始化代码的静态字段。

Answer 3

下面是一个示例，其中 volatile关键字有效地用于其预期目的。 假设我们想要实现 Task类。 我们的类仅包含两个字段，_completed 和 _result，并且仅支持两种操作：设置 _result 并仅在其为 时读取它_已完成。 让我们看看这个简单类型的无锁实现：

public class MyTask<TResult>
{
    private volatile bool _completed;
    private TResult _result;

    public void UnsafeSetResult(TResult result)
    {
        _result = result;
        _completed = true;
    }

    public bool TryGetResult(out TResult result)
    {
        if (_completed)
        {
            result = _result;
            return true;
        }
        result = default;
        return false;
    }
}

UnsafeSetResult 方法被命名为“不安全”，因为它在 MyTask 的整个生命周期内只应调用一次。代码>实例。 我们将在本答案的最后处理这个限制，但现在我们假设这个规则可以简单地通过我们的应用程序的结构来强制执行。 例如，我们可能有一个专用线程负责创建 MyTask 对象，并在它们上调用 UnsafeSetResult 。

我们必须回答的重要问题是：为什么 TryGetResult 在多线程环境中可以正确工作？ 是什么阻止调用 TryGetResult 的线程接收 撕裂 TResult 值？ 答案在于 _completed 字段被声明为 易失性，以及 _completed 和 _results 字段的顺序被分配和读取。 我们希望确保在_result的值完全存储在字段中之前，没有线程会尝试读取它。 请注意，我们对 TResult 泛型参数没有施加任何限制，因此完全有可能是一个大型结构，例如 decimal、Int128，一个 ValueTuple等。如果我们不小心，线程可能会读取半写入的 _result 值，其中一半字节仍未初始化。 这就是所谓的“撕裂”，这是我们想要防止的灾难。

我们可以通过将 _completed 设置为 true 在分配 _result 后并读取来确保不会发生撕裂_result之后我们确认_completed为true。 _completed 字段上的 volatile 关键字可确保 C# 编译器和 .NET Jitter 都不会发出以不同顺序访问/修改计算机内存的 CPU 指令。 如果您不知道，C# 编译器和 .NET Jitter 以及 CPU 处理器是 允许重新排序程序的指令，前提是这种重新排序不会影响程序在单线程上运行时的行为。

让我们看看到底对有什么影响>volatile 在 UnsafeSetResult 方法上有：

它插入一个内存屏障，防止处理器重新排序内存操作，如下所示：如果读取或写入出现在代码中的此方法之前，则处理器无法将其移到此方法之后。

换句话说，_result = result; 无法移动到 _completed = true; 之后。

现在让我们看看到底对< code>volatile 在 TryGetResult 方法上有：

它插入一个内存屏障，防止处理器重新排序内存操作，如下所示：如果代码中此方法之后出现读取或写入，则处理器无法将其移动到此方法之前。

换句话说，result = _result; 不能移动到 if (_completed) 之前。

正如您所看到的，我们在这两种方法中都需要内存屏障。 如果我们删除这两个内存屏障中的任何一个，我们程序的正确性就不再得到保证。

最后让我们看看如何实现 UnsafeSetResult 的线程安全版本。 除了 bool 字段的 false/true 值之外，我们还需要一个过渡性的“保留”状态。 因此，我们将使用 易失性 int _state 字段来代替：

public class MyTask<TResult>
{
    private volatile int _state; // 0:incomplete, 1:reserved, 2:completed
    private TResult _result;

    public bool TrySetResult(TResult result)
    {
        if (Interlocked.CompareExchange(ref _state, 1, 0) == 0)
        {
            _result = result;
            _state = 2;
            return true;
        }
        return false;
    }

    public bool TryGetResult(out TResult result)
    {
        if (_state == 2)
        {
            result = _result;
            return true;
        }
        result = default;
        return false;
    }
}

实际的 Task 类具有类似的内部 易失性 int m_stateFlags; 字段（ 源代码），其中一位以原子方式翻转（CompletionReserved，源代码）在分配内部 TResult 之前？ m_result; 字段。

Answer 4

编译器有时会更改代码中语句的顺序以对其进行优化。 通常这在单线程环境中不是问题，但在多线程环境中可能会出现问题。 请参阅以下示例：

 private static int _flag = 0;
 private static int _value = 0;

 var t1 = Task.Run(() =>
 {
     _value = 10; /* compiler could switch these lines */
     _flag = 5;
 });

 var t2 = Task.Run(() =>
 {
     if (_flag == 5)
     {
         Console.WriteLine("Value: {0}", _value);
     }
 });

如果运行 t1 和 t2，您会期望没有输出或结果为“Value: 10”。 编译器可能会在 t1 函数内切换行。 如果 t2 然后执行，则 _flag 的值为 5，但 _value 的值为 0。因此预期的逻辑可能会被破坏。

要解决此问题，您可以使用可应用于该字段的易失性关键字。 此语句禁用编译器优化，以便您可以在代码中强制执行正确的顺序。

private static volatile int _flag = 0;

仅当您确实需要时才应该使用易失性，因为它会禁用某些编译器优化，从而会损害性能。 并非所有 .NET 语言都支持它（Visual Basic 不支持它），因此它阻碍了语言的互操作性。

Answer 5

我找到了这篇文章 非常有帮助：

当您将一个对象或变量标记为易失性时，它就成为易失性读取和写入的候选者。 应该注意的是，在 C# 中，所有内存写入都是易失性的，无论您是将数据写入易失性对象还是非易失性对象。 然而，当您读取数据时，就会出现歧义。 当您读取非易失性数据时，执行线程可能会也可能不会总是获得最新值。 如果对象是易失性的，线程总是获取最新的值

Answer 6

只需查看易失性关键字的官方页面即可您可以查看典型用法的示例。

public class Worker
{
    public void DoWork()
    {
        bool work = false;
        while (!_shouldStop)
        {
            work = !work; // simulate some work
        }
        Console.WriteLine("Worker thread: terminating gracefully.");
    }
    public void RequestStop()
    {
        _shouldStop = true;
    }
    
    private volatile bool _shouldStop;
}

将 volatile 修饰符添加到 _shouldStop 的声明中后，您将始终获得相同的结果。 但是，如果 _shouldStop 成员上没有该修饰符，则行为是不可预测的。

所以这绝对不是彻头彻尾的疯狂。

存在负责 CPU 缓存一致性的缓存一致性。

另外，如果CPU采用强内存模型（作为 x86）

因此，易失性字段的读写不需要 x86 上的特殊指令：普通读写（例如使用 MOV 指令）就足够了。

C# 5.0 规范（第 10.5.3 章）中的示例

using System;
using System.Threading;
class Test
{
    public static int result;   
    public static volatile bool finished;
    static void Thread2() {
        result = 143;    
        finished = true; 
    }
    static void Main() {

        finished = false;
        new Thread(new ThreadStart(Thread2)).Start();

        for (;;) {
            if (finished) {
                Console.WriteLine("result = {0}", result);
                return;
            }
        }
    }
}

生成输出：result = 143

如果字段finished没有被声明为易失性，那么在存储完成后，主线程可以看到存储结果，因此主线程可以从该字段读取值0结果。

易失性行为依赖于平台，因此您应该根据情况需要时始终考虑使用易失性，以确保它满足您的需求。

即使易失性也无法阻止（各种）重新排序（C# - 理论与实践中的 C# 内存模型，第 2 部分)

尽管对 A 的写入是易失性的并且从 A_Won 的读取也是易失性的，但栅栏都是单向的，并且实际上允许这种重新排序。

因此，我相信，如果您想知道何时使用易失性（与lock vs Interlocked），您应该熟悉内存栅栏（全内存、半内存） ）和同步的需要。 然后你自己就会得到宝贵的答案，这对你有好处。

Answer 7

CLR 喜欢优化指令，因此当您访问代码中的字段时，它可能并不总是访问该字段的当前值（它可能来自堆栈等）。 将字段标记为易失性可确保指令访问该字段的当前值。 当程序中的并发线程或操作系统中运行的某些其他代码可以修改值（在非锁定场景中）时，这非常有用。

显然你会失去一些优化，但它确实使代码更加简单。

Answer 8

来自 MSDN：
易失性修饰符通常用于被多个线程访问而不使用lock语句来串行化访问的字段。 使用 volatile 修饰符可确保一个线程检索另一线程写入的最新值。

Answer 9

有时，编译器会优化某个字段并使用寄存器来存储它。 如果线程 1 对字段进行写入，而另一个线程访问它，则由于更新存储在寄存器（而不是内存）中，因此第二个线程将获得陈旧数据。

您可以将 volatile 关键字视为对编译器说“我希望您将此值存储在内存中”。 这保证了第二个线程检索最新值。

Answer 10

如果您使用.NET 1.1，则在执行双重检查锁定时需要 volatile 关键字。 为什么？ 因为在 .NET 2.0 之前，以下情况可能会导致第二个线程访问非 null 但尚未完全构造的对象：

1. 线程 1 询问变量是否为 null。
   //if(this.foo == null)
2. 线程1判断变量为null，因此进入锁。
   //lock(this.bar)
3. 线程 1 再次询问变量是否为 null。
   //if(this.foo == null)
4. 线程1仍然确定变量为null，因此它调用构造函数并将值赋给变量。
   //this.foo = new Foo();

在 .NET 2.0 之前，可以在构造函数完成运行之前为 this.foo 分配 Foo 的新实例。 在这种情况下，第二个线程可能会进入（在线程 1 调用 Foo 的构造函数期间）并经历以下情况：

1. 线程 2 询问变量是否为 null。
   //if(this.foo == null)
2. 线程 2 确定该变量不为 null，因此尝试使用它。
   //this.foo.MakeFoo()

在.NET 2.0之前，您可以将this.foo声明为易失性的以解决此问题。 从 .NET 2.0 开始，您不再需要使用 volatile 关键字来完成双重检查锁定。

维基百科实际上有一篇关于双重检查锁定的好文章，并简要介绍了这个主题：
http://en.wikipedia.org/wiki/Double-checked_locking

Answer 11

如果您想进一步了解 volatile 关键字的作用，请考虑以下程序（我使用的是 DevStudio 2005）：

#include <iostream>
void main()
{
  int j = 0;
  for (int i = 0 ; i < 100 ; ++i)
  {
    j += i;
  }
  for (volatile int i = 0 ; i < 100 ; ++i)
  {
    j += i;
  }
  std::cout << j;
}

使用标准优化（发布）编译器设置，编译器创建以下汇编器 (IA32)：

void main()
{
00401000  push        ecx  
  int j = 0;
00401001  xor         ecx,ecx 
  for (int i = 0 ; i < 100 ; ++i)
00401003  xor         eax,eax 
00401005  mov         edx,1 
0040100A  lea         ebx,[ebx] 
  {
    j += i;
00401010  add         ecx,eax 
00401012  add         eax,edx 
00401014  cmp         eax,64h 
00401017  jl          main+10h (401010h) 
  }
  for (volatile int i = 0 ; i < 100 ; ++i)
00401019  mov         dword ptr [esp],0 
00401020  mov         eax,dword ptr [esp] 
00401023  cmp         eax,64h 
00401026  jge         main+3Eh (40103Eh) 
00401028  jmp         main+30h (401030h) 
0040102A  lea         ebx,[ebx] 
  {
    j += i;
00401030  add         ecx,dword ptr [esp] 
00401033  add         dword ptr [esp],edx 
00401036  mov         eax,dword ptr [esp] 
00401039  cmp         eax,64h 
0040103C  jl          main+30h (401030h) 
  }
  std::cout << j;
0040103E  push        ecx  
0040103F  mov         ecx,dword ptr [__imp_std::cout (40203Ch)] 
00401045  call        dword ptr [__imp_std::basic_ostream<char,std::char_traits<char> >::operator<< (402038h)] 
}
0040104B  xor         eax,eax 
0040104D  pop         ecx  
0040104E  ret              

查看从输出中，编译器决定使用 ecx 寄存器来存储 j 变量的值。 对于非易失性循环（第一个），编译器已将 i 分配给 eax 寄存器。 非常坦率的。 不过，有一些有趣的位 - lea ebx,[ebx] 指令实际上是多字节 nop 指令，以便循环跳转到 16 字节对齐的内存地址。 另一种是使用 edx 来递增循环计数器，而不是使用 inc eax 指令。 与 inc reg 指令相比，add reg,reg 指令在一些 IA32 内核上具有较低的延迟，但从来没有更高的延迟。

现在使用易失性循环计数器进行循环。 计数器存储在 [esp] 中，并且 volatile 关键字告诉编译器应该始终从内存读取值或将值写入内存，并且永远不要将其分配给寄存器。 编译器甚至在更新计数器值时不执行加载/递增/存储三个不同的步骤（加载 eax、inc eax、保存 eax），而是直接在单个指令中修改内存（add mem ，注册）。 创建代码的方式可确保循环计数器的值在单个 CPU 内核的上下文中始终是最新的。 对数据的任何操作都不会导致损坏或数据丢失（因此不要使用加载/增量/存储，因为值可能会在增量期间发生变化，从而在存储中丢失）。 由于只有当前指令完成后才能处理中断，因此即使内存未对齐，数据也永远不会被损坏。

一旦您在系统中引入第二个 CPU，则 volatile 关键字将无法防止数据同时被另一个 CPU 更新。 在上面的示例中，您需要未对齐数据才能出现潜在的损坏。 如果数据无法以原子方式处理，则 volatile 关键字将无法防止潜在的损坏，例如，如果循环计数器的类型为 long long（64 位），则需要两次 32 位操作来更新值，在可能会发生中断并更改数据。

因此，易失性关键字仅适用于小于或等于本机寄存器大小的对齐数据，以便操作始终是原子的。

volatile 关键字被设计用于 IO 操作，其中 IO 会不断变化但具有恒定地址，例如内存映射的 UART 设备，并且编译器不应继续重用从该地址读取的第一个值。

如果您正在处理大数据或拥有多个 CPU，那么您将需要更高级别 (OS) 锁定系统来正确处理数据访问。

Answer 12

我认为没有比 Eric Lippert（原文中的强调）：

在 C# 中，“易失性”不仅意味着“确保编译器和
抖动不执行任何代码重新排序或寄存器缓存
对此变量的优化”。它也意味着“告诉处理器
尽一切努力确保我正在阅读
最新值，即使这意味着停止其他处理器并使得
它们将主内存与其缓存同步”。

事实上，最后一点是谎言。 易失性读取的真正语义
并且写入比我在这里概述的要复杂得多； 在
事实上，他们实际上并不能保证每个处理器都会停止它所要做的事情
正在执行并更新主内存的缓存。 相反，他们提供
关于读取之前和之后的内存访问方式的保证较弱
可以观察到写入是相对于彼此有序的。
某些操作，例如创建新线程、输入锁或
使用 Interlocked 系列方法之一引入更强的
保证遵守顺序。 如果您想了解更多详情，
阅读 C# 4.0 规范的第 3.10 和 10.5.3 节。

坦率地说，我不鼓励你创建一个不稳定的领域。 易挥发的
字段表明您正在做一些彻底疯狂的事情：您
尝试在两个不同的线程上读取和写入相同的值
无需上锁。 锁保证内存读取或
观察到锁内部的修改是一致的，锁保证
一次只有一个线程访问给定的内存块，所以
在。 锁太慢的情况很多
很小，并且你得到错误代码的可能性
因为你不明白确切的内存模型是非常大的。 我
除了最琐碎的代码之外，不要尝试编写任何低锁代码
联锁操作的用法。 我将“易失性”的用法留给
真正的专家。

如需进一步阅读，请参阅：

• 了解低锁技术在多线程应用中的影响
• Sayonara volatile