.NET多线程volatile优化Bug：为何Console.Write可修复该问题？

这个问题其实是.NET JIT优化和内存可见性的经典坑，咱们一步步拆解背后的原因：

先搞懂原始代码为啥会卡死 #

当开启编译优化时，第一个代码示例里的Worker线程会陷入无限循环，根本看不到主线程设置的s_stopWorker = true。这是因为JIT编译器做了一个"聪明过头"的优化：

• 它分析Worker方法的逻辑，发现循环里没有任何代码修改s_stopWorker，于是就把这个变量的值从内存读到CPU寄存器里，之后每次循环只检查寄存器里的旧值（初始是false），再也不回内存读取最新值。
• 主线程修改s_stopWorker是在内存里改的，Worker线程的寄存器里永远是false，自然永远退不出循环。

为什么Console.Write能破局？ #

你加的Console.Write(string.Empty)看似啥也没输出，但它的内部实现藏着关键：Console类的输出方法都带有线程同步逻辑——为了保证多线程输出不混乱，它会获取一个锁。而锁的获取和释放操作会自动插入内存屏障（Memory Barrier）。

内存屏障干了两件关键的事：

• 强制CPU把寄存器里的数据刷回内存，同时重新从内存读取所有变量的最新值
• 阻止JIT编译器对内存访问的指令进行重排序

所以当Worker线程执行完Console.Write后，内存屏障会逼着它下次检查s_stopWorker时，必须去内存读最新值。这时候主线程已经把s_stopWorker改成true了，Worker就能看到变化，顺利退出循环。

别靠巧合修复，用规范方案 #

虽然Console.Write能临时解决问题，但这是个"歪打正着"的 workaround，不是正经解决思路。规范的修复方式有这几种：

• 给s_stopWorker加volatile修饰符，直接告诉JIT编译器：这个变量可能被其他线程修改，不准缓存到寄存器，每次都要从内存读：

  private static volatile bool s_stopWorker;
  

• 显式插入内存屏障，比如在循环里加Thread.MemoryBarrier()：

  while (!s_stopWorker) {
      Thread.MemoryBarrier();
      x++;
  }
  

• 用更现代的线程同步工具，比如CancellationToken，这是.NET推荐的终止线程的方式，比手动控制bool变量靠谱多了。

修复后的运行结果 #

添加Console.Write后，程序能正常终止，输出如下：

Main: letting worker run for 5 seconds
Main: waiting for worker to stop
Worker: stopped when x=130084144

内容的提问来源于stack exchange，提问作者BanksySan