为什么我们需要Thread.MemoryBarrier（）？

您将很难重现此错误。实际上，我什至会说您将永远无法使用.NET
framework来重现它。原因是因为Microsoft的实现使用强大的内存模型进行写操作。这意味着将写入视为易失性。易失性写入具有锁定释放语义，这意味着必须在当前写入之前提交所有先前的写入。

但是，ECMA规范具有较弱的内存模型。因此，从理论上讲，Mono或什至是.NET framework的将来版本都有可能开始表现出越野车行为。

因此，我要说的是，消除障碍＃1和＃2几乎不会对程序的行为产生任何影响。当然，这不是保证，而是仅基于当前CLR实施的观察结果。

消除3号和4号障碍肯定会产生影响。这实际上很容易复制。好吧，本质上不是这个示例，但是以下代码是更著名的演示之一。它必须使用Release版本进行编译并在调试器之外运行。错误是程序没有结束。您可以通过

Thread.MemoryBarrier

while

stop

volatile

class Program{    static bool stop = false;    public static void Main(string[] args)    {        var t = new Thread(() =>        { Console.WriteLine("thread begin"); bool toggle = false; while (!stop) {     toggle = !toggle; } Console.WriteLine("thread end");        });        t.Start();        Thread.Sleep(1000);        stop = true;        Console.WriteLine("stop = true");        Console.WriteLine("waiting...");        t.Join();    }}

之所以难以重现某些线程错误，是因为您用来模拟线程交织的相同策略实际上可以修复该错误。

Thread.Sleep

while

您可以在此处看到我的答案，以对您引用的书中的示例进行其他分析。