閱讀目錄 背景 代碼描述 越分析越黑暗 結語 一、背景 這個標題起的有點標題黨的嫌疑[捂臉],這個事情的原委是這樣的,有個Web API的站點在本地使用Release模式Run的時候出現問題,但是使用Debug模式則不會。通過打日誌定位到問題在如下的這個代碼這裡: 理論上,會有一次請求進入到2中,但 ...
閱讀目錄
一、背景
這個標題起的有點標題黨的嫌疑[捂臉],這個事情的原委是這樣的,有個Web API的站點在本地使用Release模式Run的時候出現問題,但是使用Debug模式則不會。通過打日誌定位到問題在如下的這個代碼這裡:
private static int _flag; public void ExactlyOnceMethod() { var original = Interlocked.Exchange(ref _flag, 1); if (original == _flag) { // 1.重覆進入 } else { // 2.第一次進入 } }
理論上,會有一次請求進入到2中,但是實際問題是全部都進入到了1中。
二、代碼描述
這個代碼很簡單,就做了2個事情,1是使用Interlocked.Exchange將_flag變數進行賦值。2是將Interlocked.Exchange操作後返回的原始值與_flag變數進行對比,如果相等說明這個變數已經被修改過了,表示這裡是重入了。如果不是則說明第一次進入此方法。
關於Interlocked.Exchange的解釋,見微軟官網文檔,傳送門在此:https://msdn.microsoft.com/zh-cn/library/d3fxt78a.aspx
三、越分析越黑暗
好了,咋一看了好幾分鐘,也沒看出有什麼不妥的地方,那麼首先就往多線程問題上考慮了。但是這裡唯一的共用變數就是_flag,走的又是CAS操作,在這裡不存在多線程問題。而且結合日誌輸出,的確這個方法就是只執行了一次。仔細的再看了一遍官方文檔中的內容,見下圖1。我發現示例代碼中的寫法和我上面貼的代碼是不一樣的,這裡並沒有重用變數usingResource,而且直接將比較的對象變成了一個常量0。
【圖1】
帶著好奇,我去翻閱了下.Net Framework的源碼。傳送門在此 http://referencesource.microsoft.com/#mscorlib/system/threading/interlocked.cs,52be0cc9b3954ae9 。但是它直接是個extern方法,見下圖2:
【圖2】
這裡又陷入了一個困境,現線上索斷了。查閱了一些資料,MethodImplOptions.InternalCall 表明這個方法的實現在微軟開源的sscli中可以找到答案(原文地址 http://bbs.csdn.net/topics/330019064 中的5樓回覆)。但是經各方查找,目前已經找不到源碼所在地了,據說是.Net Framework 2.0時代的產物。
OK,那我就想看下彙編代碼試試。下麵是反編譯出的彙編代碼:
1 var original = Interlocked.Exchange(ref _flag, 1); 2 00DC35EF mov ecx,5F2DFCCh //將5F2DFCCh地址上的數據放入寄存器ecx 3 00DC35F4 mov edx,1 //將1放入寄存器edx 4 00DC35F9 call 70B95330 //調用70B95330地址上的方法 5 00DC35FE mov dword ptr [ebp-48h],eax //將寄存器eax的數據 保存到地址ebp-48h的雙字型指針上 6 00DC3601 mov eax,dword ptr [ebp-48h] //將地址ebp-48h的雙字型指針上的數據放入寄存器eax(可以理解上上一步的反向操作) 7 00DC3604 mov dword ptr [ebp-40h],eax //將寄存器eax的數據 保存到地址ebp-40h的雙字型指針上 8 if (original == _flag) 9 00DC3607 mov eax,dword ptr [ebp-40h] //將地址ebp-40h的雙字型指針上的數據放入寄存器eax 10 00DC360A cmp eax,dword ptr ds:[5F2DFCCh] //比較地址ds:[5F2DFCCh]的雙字型指針上的數據和寄存器eax中的數據。 這裡開始下麵的代碼不是我們的討論點了,就不翻譯了 11 00DC3610 setne al 12 00DC3613 movzx eax,al 13 00DC3616 mov dword ptr [ebp-44h],eax 14 00DC3619 cmp dword ptr [ebp-44h],0 15 00DC361D jne 00DC3624
這裡的5F2DFCCh其實就是_flag。我們可以看到在真正做這個Interlocked.Exchange操作的時候,並沒有直接去修改5F2DFCCh地址上的數據,但是在做cmp操作的時候由於我們比較的對象是_flag變數,所以還是繼續使用了5F2DFCCh地址上的數據。也就是說:CPU運算在寄存器中操作數據,但是我們用於判斷的變數是個靜態全局變數,持有的是這個引用地址。那麼是不是可以這麼來理解:【如果說Interlocked的內部操作與當前上下文使用的並不是同一個CPU核心】,那麼這個“判斷依據”並不是像代碼上寫的這樣,因為我們預期是肯定一樣的(變數都是同一個)。理由是做Interlocked的時候在CPU1的高速緩存中,另一個在CPU2上操作載入的數據還是記憶體中的。其中CPU1往記憶體同步數據(將寄存器中的值賦值給_flag這個全局變數)有一個非常短的時間差。如果是這樣的話,也就能解釋為什麼會有下麵的3種情況出現:
1.在有的機器上是沒問題的,在有的機器上是有問題的。
2.在Debug模式下是沒問題的,在Release模式下是有問題的。
3.在if語句之前增加一條日誌記錄到物理文件中也是沒問題的。
依據這個推測的話,原因就是因為這個時間差的耗時和所在機器的硬體配置環境都有關係。只要這個“賦值”操作所用時間 < 代碼執行到if所需的時間,那麼就不會出現問題。根據這個結論也能得出解決方案,就是讓這個表達式成立即可,哪怕就是簡單粗暴的Sleep1毫秒都行。筆者建議的解決方案有2種:
方案1:是給這個全局變數增加volatile關鍵字即可,關鍵字的說明請看這裡(https://docs.microsoft.com/zh-cn/dotnet/csharp/language-reference/keywords/volatile)。
方案2:參照官方的示例寫法,將_flag替換為常量來做比較,比如這裡可以更改成original == 0 即可。
四、結語
總結一下:
使用Interlocked做的CAS本身是一個CPU操作。數據是放在CPU的寄存器中做的交換。但是我們判斷的變數是個靜態全局變數,持有的是這個引用地址。
也就是出現問題的流程是:
1.從傳入的ref引用地址載入數據到CPU寄存器
2.寄存器中做交換並且返回原始值,但是更新引用地址的操作並不是在這個上下文中的同步操作。
3.然後我們比較的時候,左側原始值肯定為0,但是流程1中的變數在非常短的時間內也是原始值為0(如圖3)。導致了這個問題的產生。
【圖3】
強調一下,這個結論也是建立在【如果說Interlocked的內部操作與當前上下文使用的並不是同一個CPU核心】的猜測下,這方面資料實在是找不到也無法進一步驗證,所以我也不是敢100%確定是否正確。如果哪位小伙伴能夠來個明確的解惑歡迎在下麵留言~
在分析該問題的過程中,參考了以下幾位小伙伴的思想成果,感謝分享:
http://286.iteye.com/blog/2295165
http://www.cnblogs.com/5iedu/p/4719625.html
http://blog.csdn.net/hsuxu/article/details/9467651
作者:Zachary_Fan
出處:http://www.cnblogs.com/Zachary-Fan/p/interlocked.html
如果你想及時得到個人自寫文章的消息推送,歡迎掃描下麵的二維碼~。