記一次 .NET 某工廠無人車排程系統 執行緒爆高分析
一：背景
1. 講故事
前些天有位朋友找到我，說他程式中的執行緒數爆高，讓我幫忙看下怎麼回事，這種執行緒數爆高的情況找問題相對比較容易，就讓朋友丟一個dump給我，看看便知。
二：為什麼會爆高
1. 檢視託管執行緒
別人說的話不一定是真，得自己拿資料出來說話，可以用 !t 命令觀察一下便知。
0:000> !t
ThreadCount: 4683
UnstartedThread: 0
BackgroundThread: 4663
PendingThread: 0
DeadThread: 19
Hosted Runtime: no
Lock
DBG ID OSID ThreadOBJ State GC Mode GC Alloc Context Domain Count Apt Exception
0 1 cc44 00000268048778C0 202a020 Preemptive 0000000000000000:0000000000000000 00000268048c6d50 -00001 MTA
...
4670 4679 51bc 0000026D143F0420 302b220 Preemptive 0000000000000000:0000000000000000 00000268048c6d50 -00001 MTA (Threadpool Worker)
4671 4680 3a68 0000026D143F52E0 302b220 Preemptive 0000000000000000:0000000000000000 00000268048c6d50 -00001 MTA (Threadpool Worker)
4672 4681 337c 0000026D143F1140 302b220 Preemptive 0000026A88AAF5B8:0000026A88AB08D0 00000268048c6d50 -00001 MTA (Threadpool Worker)
4673 4682 188d4 0000026D143F0AB0 302b220 Preemptive 000002698881A760:000002698881C0B8 00000268048c6d50 -00001 MTA (Threadpool Worker)
4674 4683 4bcc 0000026D143EF700 302b220 Preemptive 0000026B889C4488:0000026B889C5E18 00000268048c6d50 -00001 MTA (Threadpool Worker)
從卦中資訊看確實有 4600+ 的執行緒，說明確實存在問題，接下來用 ~*e !clrstack 觀察每一個執行緒都在做什麼，執行緒太多沒法全部輸出完畢，不過很容易的看到有大量的執行緒卡在 RoutingService.Push 上，截圖如下：
接下來就是觀察下這個 Push 方法的邏輯，發現卡死在 Result 上，整理後的程式碼大概如下：
private readonly SemaphoreSlim slim = new SemaphoreSlim(1, 1);
public void Push(string xxx, xxx xxx)
{
int num = (xxx.Serial = GetSerial().Result);
}
private async Task<int> GetSerial()
{
await slim.WaitAsync();
try
{
Interlocked.Increment(ref serial);
}
finally
{
slim.Release();
}
return serial;
}
上面的程式碼看起來挺奇葩的，為什麼 GetSerial() 中不直接用 Interlocked.Increment() 呢？套一個 SemaphoreSlim 顯得非常多餘。
先不管多餘不多餘，既然 Result 得不到值，就說明這個非同步方法得不到完成，那為什麼得不到完成呢？
2. 為什麼非同步得不到完成
熟悉 SemaphoreSlim.WaitAsync() 的朋友應該知道，這裡涉及不到非同步IO，所以這個是假非同步，本質上就是動態生成了一個串聯的 Task<bool>，要想知道得不到完成的根本原因，還得要挖一挖此時的 slim 號誌情況。
0:000> !do 000002690664b5a0
Name: System.Threading.SemaphoreSlim
MethodTable: 00007ff894e56fc0
EEClass: 00007ff894e3f230
Tracked Type: false
Size: 64(0x40) bytes
File: D:\xxx\System.Private.CoreLib.dll
Fields:
MT Field Offset Type VT Attr Value Name
00007ff8948094b0 4000c2e 28 System.Int32 1 instance 0 m_currentCount
00007ff8948094b0 4000c2f 2c System.Int32 1 instance 1 m_maxCount
00007ff8948094b0 4000c30 30 System.Int32 1 instance 0 m_waitCount
00007ff8948094b0 4000c31 34 System.Int32 1 instance 0 m_countOfWaitersPulsedToWake
00007ff8962871e0 4000c32 8 ...Private.CoreLib]] 0 instance 000002690664b5e0 m_lockObjAndDisposed
00007ff894e555f0 4000c33 10 ....ManualResetEvent 0 instance 0000000000000000 m_waitHandle
00007ff894e57870 4000c34 18 ...horeSlim+TaskNode 0 instance 0000026b86919a30 m_asyncHead
00007ff894e57870 4000c35 20 ...horeSlim+TaskNode 0 instance 0000026b889c4378 m_asyncTail
00007ff894a4a1f0 4000c36 888 ...Private.CoreLib]] 0 static 00000268864f83a0 s_cancellationTokenCanceledEventHandler
從卦中看當前的 m_currentCount=0，表明當前的號誌被消費完了，所以其他的執行緒都在等待就能很好理解，接下來的問題是那個從 1->0 的持有執行緒為什麼不歸還？ 這個就比較難搞了，可以從如下兩個思路思考：
- 觀察 Result
首先懷疑是不是 Result 引發的死鎖，用 !eeversion 看了下是 asp.net core ，並沒有所謂的同步上下文，所以這個問題不存在。
0:000> !eeversion
6.0.2023.32017 free
6,0,2023,32017 @Commit: a08d9ce2caf02455c0b825bcdc32974bdf769a80
Server mode with 8 gc heaps
SOS Version: 7.0.8.30602 retail build
- 觀察程式碼
因為 SemaphoreSlim 並不記錄持有執行緒，windbg 在這裡就起不到很好的效果，不過仔細閱讀程式碼，發現應該將 await slim.WaitAsync(); 放到 try 中更合理一點，否則無法保證 WaitAsync 和 Release 一定是成雙成對的，截圖如下：
3. 什麼時候開始阻塞的
仔細觀察這個 GetSerial 方法，看看裡面的 serial 值就知道大概是進行到哪一步才出的問題。
0:4674> !DumpObj /d 000002690664b258
Name: xxx.RoutingService
MethodTable: 00007ff895283ed0
EEClass: 00007ff89526ae08
Tracked Type: false
Size: 112(0x70) bytes
File: D:\xxx\xxx.dll
Fields:
MT Field Offset Type VT Attr Value Name
...
00007ff894e56fc0 4000214 48 ...ing.SemaphoreSlim 0 instance 000002690664b5a0 slim
00007ff8948094b0 4000215 60 System.Int32 1 instance 9061 serial
從卦中看已經自增到了 9061 ，然後因為某種原因導致wait 和 release 不匹配了，像這種情況執行緒池也會有大量的任務積壓，可以用 !tp 觀察下。
0:4674> !tp
logStart: 33
logSize: 200
CPU utilization: 22 %
Worker Thread: Total: 4652 Running: 4652 Idle: 0 MaxLimit: 32767 MinLimit: 8
Work Request in Queue: 0
--------------------------------------
Number of Timers: 1
--------------------------------------
Completion Port Thread:Total: 2 Free: 2 MaxFree: 16 CurrentLimit: 2 MaxLimit: 1000 MinLimit: 8
細心的朋友會發現這裡的 Work Request in Queue: 0 ，既然是 0 何來積壓？其實這是 sos 的bug，我們需要自己到執行緒池佇列中提取，從當前的執行緒棧上尋找 ThreadPoolWorkQueue 物件即可。
0:4674> !dso
OS Thread Id: 0x4bcc (4674)
000000EF384FF5C8 0000026b06544848 System.Threading.ThreadPoolWorkQueue
0:4674> !DumpObj /d 0000026b06544848
Name: System.Threading.ThreadPoolWorkQueue
MethodTable: 00007ff894e59d80
EEClass: 00007ff894ee01d0
Tracked Type: false
Size: 168(0xa8) bytes
File: D:\xxx\System.Private.CoreLib.dll
Fields:
MT Field Offset Type VT Attr Value Name
00007ff89476bf38 4000c61 18 System.Boolean 1 instance 0 loggingEnabled
00007ff89476bf38 4000c62 19 System.Boolean 1 instance 0 _dispatchTimeSensitiveWorkFirst
00007ff89637fc20 4000c63 8 ...Private.CoreLib]] 0 instance 0000026b065448f0 workItems
00007ff89637fe00 4000c64 10 ...Private.CoreLib]] 0 instance 0000026b06544930 timeSensitiveWorkQueue
00007ff894e59d10 4000c65 20 ...acheLineSeparated 1 instance 0000026b06544868 _separated
0:4674> !ext dcq 0000026b065448f0
System.Collections.Concurrent.ConcurrentQueue<System.Object>
1 - dumpobj 0x0000026806c782f8
...
119419 - dumpobj 0x000002690a097658
119420 - dumpobj 0x000002690a097810
119421 - dumpobj 0x000002690a0981a8
---------------------------------------------
119421 items
從卦中可以看到大概有12w的積壓。上面就是我的完整分析思路，最後就是告訴朋友最好的辦法就是去掉多餘累贅的 SemaphoreSlim ，直接用同步的方式執行 Interlocked.Increment(ref serial) 即可，簡單粗暴。
三：總結
這次執行緒爆高的事故原因還是挺有意思的，用了一個雙同步來獲取 serial 值，感覺像是一種聰明反被聰明誤，程式碼一定要簡單粗暴，程式碼越少bug越少。
