对精致码农大佬的 [理解 volatile 关键字] 文章结论的思考和寻找真相
一:背景
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.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?可看出,代碼并沒有做任何優化,有點遺憾繼續看看第二階段。
3. 使用 windbg 查看 機器碼 是否被優化
很顯然機器碼給大家看也看不懂,只能看被 JIT 編譯成 機器代碼 的 匯編代碼,廢話不多說,生成一個 dump 文件.
用 name2ee 查看 DoWork 的方法描述符
從?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=02. 驗證內存中的 _shouldStop 的值
要想驗證內存中的 _shouldStop 是否已經為 true,最簡單的辦法就是去 托管堆 找 Work 對象,看看它的實例變量 _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?, 證明內存中的 _shouldStop 確實為 true,沒毛病!
3. 整體思路
到這里是不是已經非常清晰了,由于while循環太頻繁了,release做了代碼優化,將 _shouldStop 的值直接放在了 ecx 寄存器中, 當B線程執行 _shouldStop=true 更新到內存的時候,并沒有什么通知機制,導致A線程在不知情的情況下一直讀自己的 ecx 寄存器的值0,這時候就臟讀了,腦子里是不是有一張藍圖?大概就像下面這樣:
思想知道了,解決這個問題也就簡單了,給 _shouldStop 打上 volatile 標記,讓cpu每次都到內存中取 _shouldStop 值即可,
private?volatile?bool?_shouldStop;然后再看 Dowork 的反匯編:
為了更加可視化,來張對比圖,很明顯可以看到, volatile之前是直接取值比較,volatile之后是取偏移地址上的值比較,這就是真相吧!
四:總結
總的來說還是臟讀引起的問題,剛好也補充了之前文章未尋找真相的一個遺憾吧,也感謝 精致碼農大佬 原創輸出。
總結
以上是生活随笔為你收集整理的对精致码农大佬的 [理解 volatile 关键字] 文章结论的思考和寻找真相的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: 心想技术驱动业务,却在背道而驰
- 下一篇: 日计不足涓滴成河-自定义响应结果格式化器