此代码在发布模式下挂起，但在调试模式下工作正常

Question

我遇到了这个问题，想知道在调试和发布模式下出现这种行为的原因。

public static void Main(string[] args)
{            
   bool isComplete = false;

   var t = new Thread(() =>
   {
       int i = 0;

        while (!isComplete) i += 0;
   });

   t.Start();

   Thread.Sleep(500);
   isComplete = true;
   t.Join();
   Console.WriteLine("complete!");
}

Answer 1

我猜优化器被isComplete 变量上缺少'volatile' 关键字愚弄了。

当然，你不能添加它，因为它是一个局部变量。当然，因为它是一个局部变量，所以根本不需要它，因为局部变量保存在 stack 上，它们自然总是“新鲜”的。

不过，编译后，不再是局部变量。由于它是在匿名委托中访问的，因此代码被拆分，并被转换为辅助类和成员字段，例如：

public static void Main(string[] args)
{
    TheHelper hlp = new TheHelper();

    var t = new Thread(hlp.Body);

    t.Start();

    Thread.Sleep(500);
    hlp.isComplete = true;
    t.Join();
    Console.WriteLine("complete!");
}

private class TheHelper
{
    public bool isComplete = false;

    public void Body()
    {
        int i = 0;

        while (!isComplete) i += 0;
    }
}

我现在可以想象，多线程环境中的 JIT 编译器/优化器在处理 TheHelper 类时，实际上可以在开始时将值 false 缓存在某个寄存器或堆栈帧中Body() 方法，在方法结束之前永远不要刷新它。那是因为没有保证线程和方法在“=true”执行之前不会结束，所以如果没有保证，那么为什么不缓存它并获得一次读取堆对象而不是每次读取它的性能提升迭代。

这正是关键字 volatile 存在的原因。

为了让这个帮助类在多线程环境中正确 稍微好一点 ¹⁾，它应该有：

    public volatile bool isComplete = false;

但是，当然，因为它是自动生成的代码，所以您不能添加它。更好的方法是在对isCompleted 的读写周围添加一些lock()s，或者使用其他一些现成的同步或线程/任务实用程序，而不是尝试使用裸机（它 不会是裸机，因为它是 CLR 上的 C#，带有 GC、JIT 和 (..))。

调试模式的差异可能是因为在调试模式中排除了许多优化，所以你可以调试你在屏幕上看到的代码。因此while (!isComplete) 未优化，因此您可以在那里设置断点，因此isComplete 不会在方法开始时积极缓存在寄存器或堆栈中，而是在每次循环迭代时从堆上的对象中读取。

顺便说一句。这只是我对此的猜测。我什至没有尝试编译它。

顺便说一句。这似乎不是一个错误。它更像是一个非常模糊的副作用。另外，如果我是对的，那可能是语言缺陷 - C# 应该允许将“volatile”关键字放在被捕获并提升为闭包中的成员字段的局部变量上。

¹⁾ 见下文 Eric Lippert 关于 volatile 的 cmets 和/或这篇非常有趣的文章，展示了确保依赖于 volatile 的代码是 所涉及的复杂程度安全 ..uh，good ..uh，让我们说OK。

Answer 2

answer of quetzalcoatl 是正确的。为了更清楚地了解它：

允许 C# 编译器和 CLR 抖动进行大量优化，假设当前线程是唯一运行的线程。如果这些优化使程序在当前线程不是唯一运行的线程的世界中不正确那是你的问题。你需要编写多线程程序，告诉编译器和抖动你在做什么疯狂的多线程事情。

在这种特殊情况下，抖动是允许的——但不是必需的——观察循环体没有改变变量，因此得出结论——因为假设这是唯一运行的线程——变量将从不改变。如果它从不改变，则需要检查变量的真值一次，而不是每次都通过循环。事实上，这就是正在发生的事情。

如何解决这个问题？ 不要编写多线程程序。即使对于专家来说，多线程也很难做到正确。如果必须，请使用最高级别的机制来实现您的目标。这里的解决方案不是使变量易失。这里的解决方案是编写一个可取消的任务，并使用任务并行库取消机制。让 TPL 担心如何正确处理线程逻辑以及跨线程正确发送取消。

Answer 3

我附上运行的进程发现（如果我没有犯错，我对这个不是很熟练）Thread方法翻译成这样：

debug051:02DE04EB loc_2DE04EB:                            
debug051:02DE04EB test    eax, eax
debug051:02DE04ED jz      short loc_2DE04EB
debug051:02DE04EF pop     ebp
debug051:02DE04F0 retn

eax（其中包含isComplete 的值）是第一次加载并且从不刷新。

Answer 4

不是一个真正的答案，而是对这个问题有更多的了解：

问题似乎是当i 在 lambda 主体内声明时 它是 only 在赋值表达式中读取的。否则，代码在发布模式下运行良好：

1. i 在 lambda 主体之外声明：

   int i = 0; // Declared outside the lambda body
   
   var t = new Thread(() =>
   {
       while (!isComplete) { i += 0; }
   }); // Completes in release mode
   

2. i 未在赋值表达式中读取：

   var t = new Thread(() =>
   {
       int i = 0;
       while (!isComplete) { i = 0; }
   }); // Completes in release mode
   

3. i 也在其他地方被读取：

   var t = new Thread(() =>
   {
       int i = 0;
       while (!isComplete) { Console.WriteLine(i); i += 0; }
   }); // Completes in release mode
   

我敢打赌，关于 i 的一些编译器或 JIT 优化会搞砸事情。比我聪明的人可能会更清楚地了解这个问题。

不过，我不会太担心它，因为我看不出类似的代码实际上会在什么地方发挥作用。