對(duì)精致碼農(nóng)大佬的 [理解 volatile 關(guān)鍵字] 文章結(jié)論的思考和尋找真相

一：背景

1. 講故事

昨天在園里的編輯頭條看到 精致碼農(nóng)大佬 寫(xiě)的一篇題為：[C#.NET 拾遺補(bǔ)漏]10：理解 volatile 關(guān)鍵字?(https://www.cnblogs.com/willick/p/13889006.html) 的文章，大概就是說(shuō)在 多線程環(huán)境下，一個(gè)在debug不出現(xiàn)，在release中出現(xiàn)的bug，原文代碼如下：

public?class?Worker
{
????private?bool?_shouldStop;

????public?void?DoWork()
????{
????????bool?work?=?false;
????????//?注意：這里會(huì)被編譯器優(yōu)化為 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("主線程：?jiǎn)?dòng)工作線程...");
????????var?workerTask?=?Task.Run(worker.DoWork);

????????//?等待?500?毫秒以確保工作線程已在執(zhí)行
????????Thread.Sleep(500);

????????Console.WriteLine("主線程：請(qǐng)求終止工作線程...");
????????worker.RequestStop();

????????//?待待工作線程執(zhí)行結(jié)束
????????workerTask.Wait();
????????//workerThread.Join();

????????Console.WriteLine("主線程：工作線程已終止");
????}
}

文中分析這個(gè)bug是因?yàn)樵?release 環(huán)境下，jit做了?while (!_shouldStop) -> while(true)?的代碼優(yōu)化。

2. 我的質(zhì)疑

為什么我對(duì)這個(gè)問(wèn)題比較敏感呢？第一：這是一個(gè)經(jīng)典的問(wèn)題，第二：我在?2017-03-20?也寫(xiě)過(guò)一篇這樣的文章：享受release版本發(fā)布的好處的同時(shí)也應(yīng)該警惕release可能給你引入一些莫名其妙的大bug??(https://www.cnblogs.com/huangxincheng/p/6585907.html) ，那篇文章我分析是因?yàn)?cpu緩存 和 內(nèi)存 兩者之間不一致導(dǎo)致的臟讀，顯然和大佬的結(jié)論大相徑庭，而且兩篇文章都存在一個(gè)問(wèn)題，就是草率的下結(jié)論，并沒(méi)有拿出一個(gè)完整的證據(jù)鏈來(lái)證明真的是這樣， 這篇文章的目的就是試著拿出我認(rèn)為的證據(jù)鏈。

二：真的被優(yōu)化為 while(true) 了嗎

1. 從兩次編譯階段中尋找答案

大家應(yīng)該都知道代碼會(huì)經(jīng)歷兩個(gè)階段的編譯：第一階段：編譯器會(huì)把 C# code 編譯成 MSIL 代碼 ，第二階段：CLR 會(huì)啟動(dòng) JIT 將 MSIL 編譯成機(jī)器代碼，畫(huà)一張圖如下：

既然大佬說(shuō)被優(yōu)化成 while(true) 了，那意思就是說(shuō)要么在 MSIL 中被優(yōu)化，要么在 機(jī)器碼 中被優(yōu)化,這里我可以用 ILSpy 和 Windbg 去挖一挖，看看大佬說(shuō)的是否正確？

2. 用 ILSpy 查看 MSIL 是否被優(yōu)化

把項(xiàng)目編譯成 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?可看出，代碼并沒(méi)有做任何優(yōu)化，有點(diǎn)遺憾繼續(xù)看看第二階段。

3. 使用 windbg 查看 機(jī)器碼 是否被優(yōu)化

很顯然機(jī)器碼給大家看也看不懂，只能看被 JIT 編譯成 機(jī)器代碼 的 匯編代碼，廢話不多說(shuō)，生成一個(gè) 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 已經(jīng)被 JIT 編譯過(guò)了，好事情。

• 用 !U 查看 DoWork 的反匯編

對(duì)照代碼圖可以看到

• ecx 寄存器 存放著 _shouldStop 值.
• eax 寄存器 存放著 work ?值

既然有兩個(gè)寄存器存放著兩個(gè)值，也就說(shuō)明 ?while (!_shouldStop) -> while(true)?這個(gè)說(shuō)法是站不住腳的。。。那真相是什么呢？我試著揭曉。

三：我所謂的真相

1. 驗(yàn)證寄存器的值

很明顯當(dāng)前的程序正在死循環(huán)，說(shuō)明_shouldStop變量此時(shí)肯定是false，為了驗(yàn)證是否正確，通過(guò) r 命令查看一下此時(shí)寄存器的值。

0:011>?r?ecx
ecx=0

2. 驗(yàn)證內(nèi)存中的 _shouldStop 的值

要想驗(yàn)證內(nèi)存中的 _shouldStop 是否已經(jīng)為 true，最簡(jiǎn)單的辦法就是去 托管堆 找 Work 對(duì)象，看看它的實(shí)例變量 _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?, 證明內(nèi)存中的 _shouldStop 確實(shí)為 true，沒(méi)毛??！

3. 整體思路

到這里是不是已經(jīng)非常清晰了，由于while循環(huán)太頻繁了，release做了代碼優(yōu)化，將 _shouldStop 的值直接放在了 ecx 寄存器中， 當(dāng)B線程執(zhí)行 _shouldStop=true 更新到內(nèi)存的時(shí)候，并沒(méi)有什么通知機(jī)制，導(dǎo)致A線程在不知情的情況下一直讀自己的 ecx 寄存器的值0，這時(shí)候就臟讀了，腦子里是不是有一張藍(lán)圖？大概就像下面這樣：

思想知道了，解決這個(gè)問(wèn)題也就簡(jiǎn)單了，給 _shouldStop 打上 volatile 標(biāo)記，讓cpu每次都到內(nèi)存中取 _shouldStop 值即可，

private?volatile?bool?_shouldStop;

然后再看 Dowork 的反匯編：

為了更加可視化，來(lái)張對(duì)比圖，很明顯可以看到， volatile之前是直接取值比較，volatile之后是取偏移地址上的值比較，這就是真相吧！

四：總結(jié)

總的來(lái)說(shuō)還是臟讀引起的問(wèn)題，剛好也補(bǔ)充了之前文章未尋找真相的一個(gè)遺憾吧，也感謝 精致碼農(nóng)大佬 原創(chuàng)輸出。