閱讀目錄
一、背景
這個標題起的有點標題黨的嫌疑[捂臉]，這個事情的原委是這樣的，有個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
出處：https://zacharyfan.com/archives/262.html
▶關於作者：張帆（Zachary，個人微信號：Zachary-ZF）。堅持用心打磨每一篇高質量原創。歡迎掃描右側的二維碼~。
定期發表原創內容：架構設計丨分布式系統丨產品丨運營丨一些思考。
如果你是初級程序員，想提升但不知道如何下手。又或者做程序員多年，陷入了一些瓶頸想拓寬一下視野。歡迎關注我的公眾號「跨界架構師」，回復「技術」，送你一份我長期收集和整理的思維導圖。
如果你是運營，面對不斷變化的市場束手無策。又或者想了解主流的運營策略，以豐富自己的“倉庫”。歡迎關注我的公眾號「跨界架構師」，回復「運營」，送你一份我長期收集和整理的思維導圖。