盤點在Release下由循環體優化所產生的不確定性Bug
在這篇文章中，我將介紹一些在測試環境(DEBUG)下正常，但在生產環境(Release)下卻會出現的一些讓人難以捉摸的Bug。
如果你對開源技術感興趣，歡迎和我一起共同貢獻開源項目，請聯系QQ群：976304396
Debug和Release的區別
首先，Debug和Release是一種編譯常量，其決定了編譯器是否對能夠對代碼開啟優化功能。
在Release下，代碼將被編譯器進行優化，這份優化除了我們能夠在編譯后所了解的IL代碼的區別外，還包括JIT(運行時)在正式轉化為機器碼前所布置的優化內容，而最終都將以匯編的方式呈現出來.
IL代碼是一種規范，無論在哪種環境下生成代碼，都不會改變邏輯的差異，但最終生成的匯編碼卻會因為JIT的內部表現而有所不同。
因此，當出現了代碼最終執行效果和我們在腦海中所構建的邏輯效果所不同時，我們不應該以IL的角度來去思考，而是以匯編的角度來去查看到底是在哪塊有了分歧。
目錄
IL代碼無論在哪種環境都會始終表現C#代碼的原意，因此，下文的示例將不在描述IL的部分，只描述在debug和release下匯編碼的真正區別。
循環變量優化
讓我們先從一份簡單的for循環代碼開始看起：
int len = 10;
for (int i = 1; i < len; i++)
{
}
這是一個簡單的for循環邏輯，在方法內都始終存在兩個局部變量i和len，c#代碼邏輯所表述的是，我們通過訪問i的地址處的值和len的地址處的值進行比較，然后根據比較中的結果來去進行跳轉循環。而匯編碼所表述的邏輯也基本相同，但對局部變量i和len的解釋有所不同。
在Debug下，JIT將始終讀取i和len位置處的值去進行比較
L0023: mov dword ptr [ebp-8], 0xa //assign len
L002a: mov dword ptr [ebp-0xc], 1 //assign i
...
L0036: mov eax, [ebp-0xc]
L0039: inc eax //i++
L003a: mov [ebp-0xc], eax //update i
L003d: mov eax, [ebp-0xc]
L0040: cmp eax, [ebp-8] //compare
而在Release下，JIT將i的變量始終存儲在寄存器中，對於len,則以常量代替.
L0003: mov eax, 1
L0008: inc eax
L0009: cmp eax, 0xa
Release較Debug的變化是：JIT知道在當前方法上下文中，len是個局部變量，且始終不會改變，因此可以提升為常量，這樣當進行比較時，可以不用每次都進行訪問。i也是個局部變量，且每次增加固定的常量1，因此i也不需要在棧中存儲，可以直接保留在寄存器中，這樣不會有取址的開銷。
上述例子說明了，在一定的條件下，編譯器會對循環體中進行比較的變量進行特殊的優化，通過避免在地址中取值，以提升循環的效率。
注:由於CPU對指令執行的速度遠高於訪問內存的速度,因此相比較對內存進行訪問是一種開銷,在訪問性能中,寄存器>cpu緩存行>主存.
性能差異
讓我們通過下面一個例子來看一下，使用寄存器和不使用寄存器來保存循環變量所帶來的性能差異:
public void Test1()
{
int count = 0;
for (int i = 1; i < 1000; i++)
{
ref _Int32 r = ref Unsafe.As<int, _Int32>(ref i);
count += r.int32;
}
}
public void Test2()
{
int count = 0;
for (int i = 1; i < 1000; i++)
{
_Int32 r = Unsafe.As<int, _Int32>(ref i);
count += r.int32;
}
}
請通過Benchmark來對Test1和Test2進行測試，你會發現，兩個方法之間的性能差別非常大，Test2的性能要遠超Test1。
BenchmarkDotNet=v0.12.1, OS=Windows 10.0.17763.1518 (1809/October2018Update/Redstone5)
Intel Core i7-7700HQ CPU 2.80GHz (Kaby Lake), 1 CPU, 8 logical and 4 physical cores
.NET Core SDK=3.1.402
[Host] : .NET Core 3.1.8 (CoreCLR 4.700.20.41105, CoreFX 4.700.20.41903), X64 RyuJIT
DefaultJob : .NET Core 3.1.8 (CoreCLR 4.700.20.41105, CoreFX 4.700.20.41903), X64 RyuJIT
| Method | Mean | Error | StdDev |
|---|---|---|---|
| Test1 | 2,261.6 ns | 12.62 ns | 11.80 ns |
| Test2 | 308.3 ns | 3.43 ns | 3.04 ns |
近乎相同的代碼,為什么會有如此的差異?
如果我們對其生成的匯編代碼進行查看的話，你會發現在Test1中，對變量i的訪問，將始終通過尋址來去查找:
L000b: mov dword ptr [ebp-4], 1
L0027: cmp dword ptr [ebp-4], 0x3e8
...
L0020: mov edx, [ebp-4]
L0023: inc edx
...
L0024: mov [ebp-4], edx
L0027: cmp dword ptr [ebp-4], 0x3e8
而在Test2中,則始終通過在寄存器中存儲的值直接獲取:
L000c: inc edx
L000d: cmp edx, 0x3e8
在Test2方法中，因為變量i沒有被造成污染，因此最終代碼等價於 count += i ， 而在Test1方法中， 因為ref關鍵字的影響,導致了該代碼破壞了jit對循環變量的優化規則，最終無法使用寄存器來直接存儲變量i，產生了性能的差異。
因此，在往后對循環體的編程中，若代碼主體不會改變循環變量的值的話，那么盡量可以在循環體中創建一個副本來去使用，這樣對性能可以有效的提升。
注：
ref Unsafe.As<int, _Int32>(ref i)等價於(_Int32*)&i
Unsafe.As<int, _Int32>(ref i)等價於*(_Int32*)&i
潛在的Bug
介紹完通過將循環變量直接存儲在寄存器中的方式所帶來的性能提升后，下面我將介紹因為這種jit優化的方式所帶來的潛在性Bug。
for和while是在語法上有所不同，但最終執行表現是相同的，因此，為了后面的例子中所展示的邏輯更直白，對於循環的語法，我將使用do while來描述。
循環變量不變
[Fact]
public void Test1()
{
int i = 1;
Task.Run(() => { i = int.MinValue; });
do { }
while (i > 0);
}
這段代碼的邏輯是這樣的:
- 主線程將無限進行循環,直到
i<=0才結束. - 第二條線程將改變
i的值以讓它小於等於0
按照正常邏輯來走，第二條線程一定會執行改變值的代碼，因此方法在運行后始終會終止(會因主線程跳出循環的結束而結束).
但這個邏輯實際上只在Debug下是正常的，在Release下，該程序將永遠不會結束。不信, 你可以嘗試下.
注意，這里只是通過值類型舉例說明，平常的編程習慣更多的是引用類型，如下:
object var = new object();
Task.Run(() => { var = null; });
do { }
while (var != null);
為什么會出現這樣的情況?
c#中寫是易失性寫，讀是非易失性讀，在本文中可以理解為，c#會對對象讀取做一定的優化。
在第二段中，我已經舉例介紹了這種優化，這取決於JIT是否能跟蹤到代碼對變量i的更改，若JIT通過中間形式解析后能夠跟蹤到對循環變量的修改，則對循環變量將不會使用寄存器來進行優化。
下面上述例子在DEBUG下的匯編，可以看到，最終對i的比較和賦值的是同一個地址：
L007e: cmp dword ptr [eax+4], 0
mov dword ptr [eax+4], 0x80000000
下面上述例子在Release下的匯編，可以看到，最終對i的比較和賦值不是同一個地址：
L0037: mov eax, [esi+4]
L003a: test eax, eax
mov dword ptr [ecx+4], 0x80000000
在本例中，因為JIT在沒能跟蹤到委托中的循環變量，最終取i的地址和在委托的閉包中設置的i的地址不是同一個位置，因此會產生無限輪訓。
解決方法也很簡單, 可以通過 Volatile.Read(ref i) 的方式來去閱讀它，這樣，編譯器將只是把i變量保留在eax中，且每次訪問都將從新取址獲取它。
或者像下面這兩個例子一樣，讓JIT能夠跟蹤到代碼對i的修改：
public void Test1()
{
int i = 1;
Task.Run(() => { i = int.MinValue; });
do { i++; }
while (i > 0);
}
public void Test1()
{
int i = 1;
Task.Run(() => { i = int.MinValue; });
do { Aux(ref i); }
while (i > 0);
}
private void Aux(ref int var)
{
var++;
}
stackalloc不清零
在我編寫Bssom.Net(一個結構化的高性能二進制序列化器)時，曾碰見了一個Bug，同樣的代碼在Debug下進行單元測試時是沒問題的，在Release下卻會發生錯誤，最后經過排查並通過官方的幫助已確定是一個JIT的內部Bug，在此把它分享出來。
運行如下示例
public void Test1()
{
for (int i = 1; i >= 0; i--)
{
Console.WriteLine(Test(i));
}
}
public byte Test(int i)
{
byte* c = stackalloc byte[8];
c[i] = 42;
return c[1];
}
這個示例在Debug下輸出 42，0
但是在Release下卻輸出 42，42
這意味着在Release下的stackalloc沒有對棧內存進行清零，這可能會因為使用到了未清零的數據而導致錯誤的邏輯產生。
而之所以會出現這樣的情況，這是因為JIT會對小的stackalloc分配代碼(本例中是8個字節)進行內聯，我們可以在Release下看到Test1方法在循環外只進行一次0初始化，而不是每次調用Test方法並在Test方法中進行重新分配。
xor eax, eax
mov[ebp - 0xc], eax
mov[ebp - 8], eax
mov[ebp - 4], eax
...
L001d: lea edx, [ebp-0xc]
L002b: jge short L001d
這種情況源自JIT內部對stackalloc內聯的判斷邏輯不夠具體，這個bug目前已經被修復，將添加在未來.net版本中。
那么，在當下版本(示例是使用net core3.1版本)中，我們該如何避免這種情況的產生?我給出了幾個參考：
- 如果邏輯允許的話，盡可能的將
stackalloc提出循環外 - 使用同等寬度字節進行初始化而不是
stackalloc，如long - 使用
Span去創建Stackalloc，且通過Span.Clear方法來手動清空. - 為方法標記
[MethodImpl(MethodImplOptions.NoInlining)]
當然，如果通過stackalloc分配的內存超出32字節，則不必擔心會出現本例中的情況，因為目前來說，JIT不會內聯stackalloc分配超出32字節的方法。
其它
作者：小曾
出處：https://www.cnblogs.com/1996V/p/13909855.html 歡迎轉載，但請保留以上完整文章，在顯要地方顯示署名以及原文鏈接。
Net開源技術交流群 976304396 , 抖音賬號: 198152455