一：背景

1. 講故事

昨天在園里的編輯頭條看到 精致碼農(nóng)大佬 寫的一篇題為：[C#.NET 拾遺補(bǔ)漏]10：理解 volatile 關(guān)鍵字?(https://www.cnblogs.com/willick/p/13889006.html) 的文章，大概就是說在 多線程環(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("主線程：啟動(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è)問題比較敏感呢？第一：這是一個(gè)經(jīng)典的問題，第二：我在?2017-03-20?也寫過一篇這樣的文章：享受release版本發(fā)布的好處的同時(shí)也應(yīng)該警惕release可能給你引入一些莫名其妙的大bug??(https://www.cnblogs.com/huangxincheng/p/6585907.html) ，那篇文章我分析是因?yàn)?cpu緩存 和 內(nèi)存 兩者之間不一致導(dǎo)致的臟讀，顯然和大佬的結(jié)論大相徑庭，而且兩篇文章都存在一個(gè)問題，就是草率的下結(jié)論，并沒有拿出一個(gè)完整的證據(jù)鏈來證明真的是這樣， 這篇文章的目的就是試著拿出我認(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ī)器代碼，畫一張圖如下：

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

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.0IL_0001:?stloc.0IL_0002:?br.s?IL_0009//?loop?start?(head:?IL_0009)IL_0004:?ldloc.0IL_0005:?ldc.i4.0IL_0006:?ceqIL_0008:?stloc.0IL_0009:?ldarg.0IL_000a:?ldfld?bool?ConsoleApp1.Worker::_shouldStopIL_000f:?brfalse.s?IL_0004//?end?loopIL_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?可看出，代碼并沒有做任何優(yōu)化，有點(diǎn)遺憾繼續(xù)看看第二階段。

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

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

• 用 !U 查看 DoWork 的反匯編

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

• ecx 寄存器 存放著 _shouldStop 值.

• eax 寄存器 存放著 work ?值

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

三：我所謂的真相

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

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

0:011>?r?ecx ecx=0

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

要想驗(yàn)證內(nèi)存中的 _shouldStop 是否已經(jīng)為 true，最簡單的辦法就是去 托管堆 找 Work 對(duì)象，看看它的實(shí)例變量 _shouldStop 是否為 true 即可。

0:011>?!dumpheap?-stat Statistics:MT????Count????TotalSize?Class?Name 00007ffc8fdd3a90????????1???????????24?ConsoleApp1.Worker0:011>?!dumpheap?-mt?00007ffc8fdd3a90Address???????????????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，沒毛病！

3. 整體思路

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

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

private?volatile?bool?_shouldStop;

然后再看 Dowork 的反匯編：

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

四：總結(jié)

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

總結(jié)

以上是生活随笔為你收集整理的对精致码农大佬的 [理解 volatile 关键字] 文章结论的思考和寻找真相的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。