## 一：背景 ### 1. 講故事 昨天在園裡的編輯頭條看到 精緻碼農大佬 寫的一篇題為：`[C#.NET 拾遺補漏]10：理解 volatile 關鍵字` (https://www.cnblogs.com/willick/p/13889006.html) 的文章，大概就是說在 多執行緒環境下，一個在debug不出現，在release中出現的bug，原文程式碼如下： ``` C# 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，如下所示： ``` C# .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 的方法描述符 ``` C# 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 命令檢視一下此時暫存器的值。 ``` C# 0:011> r ecx ecx=0 ``` ### 2. 驗證記憶體中的 _shouldStop 的值 要想驗證記憶體中的 _shouldStop 是否已經為 true，最簡單的辦法就是去 託管堆 找 Work 物件，看看它的例項變數 _shouldStop 是否為 true 即可。 ``` C# 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 值即可， ``` C# private volatile bool _shouldStop; ``` 然後再看 Dowork 的反彙編：  為了更加視覺化，來張對比圖，很明顯可以看到， volatile之前是直接取值比較，volatile之後是取偏移地址上的值比較，這就是真相吧！  ## 四：總結 總的來說還是髒讀引起的問題，剛好也補充了之前文章未尋找真相的一個遺憾吧，也感謝 精緻碼農大佬 原創輸出。 **更多高質量乾貨：參見我的 GitHub: [dotnetfly](https://github.com/ctripxchuang/dotnetfly)**