中興AX5400Pro+上手體驗(yàn)：再升級(jí) 雙2.5G網(wǎng)口+USB 3.0這次全都有
2021年11月的時(shí)候，中興先后發(fā)布了兩款路由器產(chǎn)品，中興AX5400和中興AX5400 Pro，從產(chǎn)品命名上就不難看出這是隸屬于同一系列的，但在外觀設(shè)計(jì)上這兩款產(chǎn)品可以說(shuō)是完全沒(méi)一點(diǎn)關(guān)系
前些天有位朋友找到我，說(shuō)他程序中的線程數(shù)爆高，讓我?guī)兔聪略趺椿厥拢@種線程數(shù)爆高的情況找問(wèn)題相對(duì)比較容易，就讓朋友丟一個(gè)dump給我，看看便知。
別人說(shuō)的話不一定是真，得自己拿數(shù)據(jù)出來(lái)說(shuō)話，可以用 !t 命令觀察一下便知。
0:000> !tThreadCount: 4683UnstartedThread: 0BackgroundThread: 4663PendingThread: 0DeadThread: 19Hosted 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)從卦中信息看確實(shí)有 4600+ 的線程，說(shuō)明確實(shí)存在問(wèn)題，接下來(lái)用 ~*e !clrstack 觀察每一個(gè)線程都在做什么，線程太多沒(méi)法全部輸出完畢，不過(guò)很容易的看到有大量的線程卡在 RoutingService.Push 上，截圖如下：
圖片
接下來(lái)就是觀察下這個(gè) Push 方法的邏輯，發(fā)現(xiàn)卡死在 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;}上面的代碼看起來(lái)挺奇葩的，為什么 GetSerial() 中不直接用 Interlocked.Increment() 呢？套一個(gè) SemaphoreSlim 顯得非常多余。
先不管多余不多余，既然 Result 得不到值，就說(shuō)明這個(gè)異步方法得不到完成，那為什么得不到完成呢？
熟悉 SemaphoreSlim.WaitAsync() 的朋友應(yīng)該知道，這里涉及不到異步IO，所以這個(gè)是假異步，本質(zhì)上就是動(dòng)態(tài)生成了一個(gè)串聯(lián)的 Task<bool>，要想知道得不到完成的根本原因，還得要挖一挖此時(shí)的 slim 信號(hào)量情況。
0:000> !do 000002690664b5a0Name: System.Threading.SemaphoreSlimMethodTable: 00007ff894e56fc0EEClass: 00007ff894e3f230Tracked Type: falseSize: 64(0x40) bytesFile: D:/xxx/System.Private.CoreLib.dllFields: MT Field Offset Type VT Attr Value Name00007ff8948094b0 4000c2e 28 System.Int32 1 instance 0 m_currentCount00007ff8948094b0 4000c2f 2c System.Int32 1 instance 1 m_maxCount00007ff8948094b0 4000c30 30 System.Int32 1 instance 0 m_waitCount00007ff8948094b0 4000c31 34 System.Int32 1 instance 0 m_countOfWaitersPulsedToWake00007ff8962871e0 4000c32 8 ...Private.CoreLib]] 0 instance 000002690664b5e0 m_lockObjAndDisposed00007ff894e555f0 4000c33 10 ....ManualResetEvent 0 instance 0000000000000000 m_waitHandle00007ff894e57870 4000c34 18 ...horeSlim+TaskNode 0 instance 0000026b86919a30 m_asyncHead00007ff894e57870 4000c35 20 ...horeSlim+TaskNode 0 instance 0000026b889c4378 m_asyncTail00007ff894a4a1f0 4000c36 888 ...Private.CoreLib]] 0 static 00000268864f83a0 s_cancellationTokenCanceledEventHandler從卦中看當(dāng)前的 m_currentCount=0，表明當(dāng)前的信號(hào)量被消費(fèi)完了，所以其他的線程都在等待就能很好理解，接下來(lái)的問(wèn)題是那個(gè)從 1->0 的持有線程為什么不歸還？這個(gè)就比較難搞了，可以從如下兩個(gè)思路思考：
首先懷疑是不是 Result 引發(fā)的死鎖，用 !eeversion 看了下是 asp core ，并沒(méi)有所謂的同步上下文，所以這個(gè)問(wèn)題不存在。
0:000> !eeversion6.0.2023.32017 free6,0,2023,32017 @Commit: a08d9ce2caf02455c0b825bcdc32974bdf769a80Server mode with 8 gc heapsSOS Version: 7.0.8.30602 retail build因?yàn)?SemaphoreSlim 并不記錄持有線程，windbg 在這里就起不到很好的效果，不過(guò)仔細(xì)閱讀代碼，發(fā)現(xiàn)應(yīng)該將 await slim.WaitAsync(); 放到 try 中更合理一點(diǎn)，否則無(wú)法保證 WaitAsync 和 Release 一定是成雙成對(duì)的，截圖如下：
圖片
仔細(xì)觀察這個(gè) GetSerial 方法，看看里面的 serial 值就知道大概是進(jìn)行到哪一步才出的問(wèn)題。
0:4674> !DumpObj /d 000002690664b258Name: xxx.RoutingServiceMethodTable: 00007ff895283ed0EEClass: 00007ff89526ae08Tracked Type: falseSize: 112(0x70) bytesFile: D:/xxx/xxx.dllFields: MT Field Offset Type VT Attr Value Name...00007ff894e56fc0 4000214 48 ...ing.SemaphoreSlim 0 instance 000002690664b5a0 slim00007ff8948094b0 4000215 60 System.Int32 1 instance 9061 serial從卦中看已經(jīng)自增到了 9061 ，然后因?yàn)槟撤N原因?qū)е聎ait 和 release 不匹配了，像這種情況線程池也會(huì)有大量的任務(wù)積壓，可以用 !tp 觀察下。
0:4674> !tplogStart: 33logSize: 200CPU utilization: 22 %Worker Thread: Total: 4652 Running: 4652 Idle: 0 MaxLimit: 32767 MinLimit: 8Work Request in Queue: 0--------------------------------------Number of Timers: 1--------------------------------------Completion Port Thread:Total: 2 Free: 2 MaxFree: 16 CurrentLimit: 2 MaxLimit: 1000 MinLimit: 8細(xì)心的朋友會(huì)發(fā)現(xiàn)這里的 Work Request in Queue: 0 ，既然是 0 何來(lái)積壓？其實(shí)這是 sos 的bug，我們需要自己到線程池隊(duì)列中提取，從當(dāng)前的線程棧上尋找 ThreadPoolWorkQueue 對(duì)象即可。
0:4674> !dsoOS Thread Id: 0x4bcc (4674)000000EF384FF5C8 0000026b06544848 System.Threading.ThreadPoolWorkQueue0:4674> !DumpObj /d 0000026b06544848Name: System.Threading.ThreadPoolWorkQueueMethodTable: 00007ff894e59d80EEClass: 00007ff894ee01d0Tracked Type: falseSize: 168(0xa8) bytesFile: D:/xxx/System.Private.CoreLib.dllFields: MT Field Offset Type VT Attr Value Name00007ff89476bf38 4000c61 18 System.Boolean 1 instance 0 loggingEnabled00007ff89476bf38 4000c62 19 System.Boolean 1 instance 0 _dispatchTimeSensitiveWorkFirst00007ff89637fc20 4000c63 8 ...Private.CoreLib]] 0 instance 0000026b065448f0 workItems00007ff89637fe00 4000c64 10 ...Private.CoreLib]] 0 instance 0000026b06544930 timeSensitiveWorkQueue00007ff894e59d10 4000c65 20 ...acheLineSeparated 1 instance 0000026b06544868 _separated0:4674> !ext dcq 0000026b065448f0System.Collections.Concurrent.ConcurrentQueue<System.Object> 1 - dumpobj 0x0000026806c782f8...119419 - dumpobj 0x000002690a097658119420 - dumpobj 0x000002690a097810119421 - dumpobj 0x000002690a0981a8---------------------------------------------119421 items從卦中可以看到大概有12w的積壓。上面就是我的完整分析思路，最后就是告訴朋友最好的辦法就是去掉多余累贅的 SemaphoreSlim ，直接用同步的方式執(zhí)行 Interlocked.Increment(ref serial) 即可，簡(jiǎn)單粗暴。
這次線程爆高的事故原因還是挺有意思的，用了一個(gè)雙同步來(lái)獲取 serial 值，感覺(jué)像是一種聰明反被聰明誤，代碼一定要簡(jiǎn)單粗暴，代碼越少bug越少。
本文鏈接：http://www.www897cc.com/showinfo-26-16403-0.html記一次 .NET 某工廠無(wú)人車調(diào)度系統(tǒng) 線程爆高分析
聲明：本網(wǎng)頁(yè)內(nèi)容旨在傳播知識(shí)，若有侵權(quán)等問(wèn)題請(qǐng)及時(shí)與本網(wǎng)聯(lián)系，我們將在第一時(shí)間刪除處理。郵件：2376512515@qq.com
上一篇： 一文學(xué)會(huì)Python面向?qū)ο笾蟹庋b、繼承、多態(tài)使用
下一篇： 幾行代碼教你抓包
Copyright ? 2016-2023 天津谷騏科技有限公司 版權(quán)所有 sitemap.xml
違法及侵權(quán)請(qǐng)聯(lián)系：2376512515@qq.com 津ICP備18001702號(hào)
津公網(wǎng)安備 12010102000574號(hào)