對精緻碼農大佬的 [理解 volatile 關鍵字] 文章結論的思考和尋找真相

一：背景

1. 講故事

昨天在園裏的編輯頭條看到 精緻碼農大佬 寫的一篇題爲：[C#.NET 拾遺補漏]10：理解 volatile 關鍵字 (http://www.javashuo.com/article/p-vvxoryuq-nu.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 (http://www.javashuo.com/article/p-zaicaxbv-gy.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