一：背景
1. 講故事
昨天在園裡的編輯頭條看到 精緻碼農大佬 寫的一篇題為：
[C#.NET 拾遺補漏]10：了解 volatile 關鍵字
(https://www.cnblogs.com/willick/p/13889006.html) 的文章，大概就是說在 多線程環境下，一個在debug不出現，在release中出現的bug，原文代碼如下：
public class Worker
{
private bool _shouldStop;
public void DoWork()
{
bool work = false;
// 注意：這裡會被編譯器優化為 while(true)
while (!_shouldStop)
{
work = !work; // do sth.
}
Console.WriteLine("工作線程：正在終止...");
}
public void RequestStop()
{
_shouldStop = true;
}
}
public class Program
{
public static void Main()
{
var worker = new Worker();
Console.WriteLine("主線程：啟動工作線程...");
var workerTask = Task.Run(worker.DoWork);
// 等待 500 毫秒以確定工作線程已在執行
Thread.Sleep(500);
Console.WriteLine("主線程：請求終止工作線程...");
worker.RequestStop();
// 待待工作線程執行結束
workerTask.Wait();
//workerThread.Join();
Console.WriteLine("主線程：工作線程已終止");
}
}
文中分析這個bug是因為在 release 環境下，jit做了
while (!_shouldStop) -> while(true)
的代碼優化。
2. 我的質疑
為什麼我對這個問題比較敏感呢？第一：這是一個經典的問題，第二：我在
2017-03-20
也寫過一篇這樣的文章：
享受release版本釋出的好處的同時也應該警惕release可能給你引入一些莫名其妙的大bug
(https://www.cnblogs.com/huangxincheng/p/6585907.html) ，那篇文章我分析是因為 cpu緩存 和 記憶體 兩者之間不一緻導緻的髒讀，顯然和大佬的結論大相徑庭，而且兩篇文章都存在一個問題，就是草率的下結論，并沒有拿出一個完整的證據鍊來證明真的是這樣， 這篇文章的目的就是試着拿出我認為的證據鍊。
二：真的被優化為 while(true) 了嗎
1. 從兩次編譯階段中尋找答案
大家應該都知道代碼會經曆兩個階段的編譯： 第一階段：編譯器會把 C# code 編譯成 MSIL 代碼 ，第二階段： CLR 會啟動 JIT 将 MSIL 編譯成機器代碼，畫一張圖如下：
既然大佬說被優化成 while(true) 了，那意思就是說要麼在 MSIL 中被優化，要麼在 機器碼 中被優化,這裡我可以用 ILSpy 和 Windbg 去挖一挖，看看大佬說的是否正确？
2. 用 ILSpy 檢視 MSIL 是否被優化
把項目編譯成 release 模式，直接檢視
DoWork()
的MSIL，如下所示：
.method public hidebysig
instance void DoWork () cil managed
{
// Method begins at RVA 0x2048
// Code size 28 (0x1c)
.maxstack 2
.locals init (
[0] bool work
)
IL_0000: ldc.i4.0
IL_0001: stloc.0
IL_0002: br.s IL_0009
// loop start (head: IL_0009)
IL_0004: ldloc.0
IL_0005: ldc.i4.0
IL_0006: ceq
IL_0008: stloc.0
IL_0009: ldarg.0
IL_000a: ldfld bool ConsoleApp1.Worker::_shouldStop
IL_000f: brfalse.s IL_0004
// end loop
IL_0011: ldstr "工作線程：正在終止..."
IL_0016: call void [System.Console]System.Console::WriteLine(string)
IL_001b: ret
} // end of method Worker::DoWork
從這句：
ldfld bool ConsoleApp1.Worker::_shouldStop
可看出，代碼并沒有做任何優化，有點遺憾繼續看看第二階段。
3. 使用 windbg 檢視 機器碼 是否被優化
很顯然機器碼給大家看也看不懂，隻能看被 JIT 編譯成 機器代碼 的 彙編代碼，廢話不多說，生成一個 dump 檔案.
- 用 name2ee 檢視 DoWork 的方法描述符
0:011> !name2ee ConsoleApp1!Worker.DoWork
Module: 00007ffc8fdaf7e0
Assembly: ConsoleApp1.dll
Token: 0000000006000001
MethodDesc: 00007ffc8fdd3a50
Name: ConsoleApp1.Worker.DoWork()
JITTED Code Address: 00007ffc8fd17500
從
JITTED Code Address: 00007ffc8fd17500
可以看到，DoWork 已經被 JIT 編譯過了，好事情。
- 用 !U 檢視 DoWork 的反彙編
對照代碼圖可以看到
- ecx 寄存器 存放着 _shouldStop 值.
- eax 寄存器 存放着 work 值
既然有兩個寄存器存放着兩個值，也就說明
while (!_shouldStop) -> while(true)
這個說法是站不住腳的。。。 那真相是什麼呢？ 我試着揭曉。
三：我所謂的真相
1. 驗證寄存器的值
很明顯目前的程式正在死循環，說明_shouldStop變量此時肯定是false，為了驗證是否正确，通過 r 指令檢視一下此時寄存器的值。
0:011> r ecx
ecx=0
2. 驗證記憶體中的 _shouldStop 的值
要想驗證記憶體中的 _shouldStop 是否已經為 true，最簡單的辦法就是去 托管堆 找 Work 對象，看看它的執行個體變量 _shouldStop 是否為 true 即可。
0:011> !dumpheap -stat
Statistics:
MT Count TotalSize Class Name
00007ffc8fdd3a90 1 24 ConsoleApp1.Worker
0:011> !dumpheap -mt 00007ffc8fdd3a90
Address MT Size
000001ee59f4abd8 00007ffc8fdd3a90 24
0:011> !do 000001ee59f4abd8
Name: ConsoleApp1.Worker
MethodTable: 00007ffc8fdd3a90
EEClass: 00007ffc8fdccda8
Size: 24(0x18) bytes
File: E:\net5\ConsoleApp1\ConsoleApp1\bin\x64\Release\netcoreapp3.1\ConsoleApp1.dll
Fields:
MT Field Offset Type VT Attr Value Name
00007ffc8fcd71d0 4000001 8 System.Boolean 1 instance 1 _shouldStop
從最後一行代碼可以看到：
_shouldStop =1
, 證明記憶體中的 _shouldStop 确實為 true，沒毛病！
3. 整體思路
到這裡是不是已經非常清晰了，由于while循環太頻繁了，release做了代碼優化，将 _shouldStop 的值直接放在了 ecx 寄存器中， 當B線程執行 _shouldStop=true 更新到記憶體的時候，并沒有什麼通知機制，導緻A線程在不知情的情況下一直讀自己的 ecx 寄存器的值0，這時候就髒讀了，腦子裡是不是有一張藍圖？ 大概就像下面這樣：
思想知道了，解決這個問題也就簡單了，給 _shouldStop 打上 volatile 标記，讓cpu每次都到記憶體中取 _shouldStop 值即可，
private volatile bool _shouldStop;
然後再看 Dowork 的反彙編：
為了更加可視化，來張對比圖，很明顯可以看到， volatile之前是直接取值比較，volatile之後是取偏移位址上的值比較，這就是真相吧！
四：總結
總的來說還是髒讀引起的問題，剛好也補充了之前文章未尋找真相的一個遺憾吧，也感謝 精緻碼農大佬 原創輸出。
更多高品質幹貨：參見我的 GitHub: dotnetfly