前段時間，有個朋友來找我，說他們的程式CPU爆炸了，讓我幫忙看看是怎麼回事？解決這個問題的最好方法是抓取乙個轉儲並扔給我，推薦的工具是使用 procdump 來自動捕獲。
還是老規矩，想找到這個答案，可以用！tp 命令。
0:044> !tplogstart: 1logsize: 200cpu utilization: 88 %worker thread: total: 8 running: 4 idle: 4 maxlimit: 1023 minlimit: 4work request in queue: 0---number of timers: 2---completion port thread:total: 2 free: 2 maxfree: 8 currentlimit: 2 maxlimit: 1000 minlimit: 40:044> !cpuidcp f/m/s manufacturer mhz 0 6,94,3 genuineintel 3192 1 6,94,3 genuineintel 3192 2 6,94,3 genuineintel 3192 3 6,94,3 genuineintel 3192導致CPU爆裂的因素有很多，沒有標準答案，需要自己找原因，首先我們來觀察一下這個程式中的執行緒數，就可以使用了！t 命令。
0:044> !tthreadcount: 451unstartedthread: 0backgroundthread: 443pendingthread: 0deadthread: 1hosted runtime: no lock dbg id osid threadobj state gc mode gc alloc context domain count apt exception 0 1 22b8 04ce8728 26020 preemptive 18e5c92c:18e5e4dc 04c86c20 -00001 sta 3 2 17c8 04b25768 2b220 preemptive 18caf3a0:18cb1374 04c86c20 -00001 mta (finalizer) 4 4 238c 04c0cdd8 202b020 preemptive 18e45d88:18e464dc 04c86c20 -00001 mta 5 5 230c 0a6c37a0 202b020 preemptive 18dac318:18dac47c 04c86c20 -00001 mta 6 6 23a0 0a70e620 202b220 preemptive 00000000:00000000 04c86c20 -00001 mta ..下乙個想法是使用 *e ！clrstack 命令觀察每個執行緒此時在做什麼，一旦輸入命令，刷子就需要很長時間。
0:044> ~e !clrstack...os thread id: 0x220c (18)child sp ip call site184cf614 77dd19dc [helpermethodframe: 184cf614] system.threading.thread.sleepinternal(int32)184cf680 141975f4 system.threading.thread.sleep(int32) [/_/src/libraries/system.private.corelib/src/system/threading/thread.cs @ 357]184cf694 165055b9 xxx.actionthread`1[[xxx]].loop()184cf878 74467741 system.threading.thread+starthelper.callback(system.object) [/_/src/libraries/system.private.corelib/src/system/threading/thread.cs @ 42]184cf888 7446fca1 system.threading.executioncontext.runinternal(system.threading.executioncontext, system.threading.contextcallback, system.object) [/_/src/libraries/system.private.corelib/src/system/threading/executioncontext.cs @ 183]184cf8c0 74466742 system.threading.thread.startcallback() /_/src/coreclr/system.private.corelib/src/system/threading/thread.coreclr.cs @ 105]184cfa14 74cbc29f [debuggeru2mcatchhandlerframe: 184cfa14] .CPU不能無緣無故地爆炸，總是那些執行緒被提公升，但這個程式中的大多數執行緒都線上程中Sleepinternal，說他們可以炸毀 CPU 有點牽強。
但問題必須解決，在沒有突破的情況下，你只能咬緊牙關sleepinternal 強行突破，先用 ctrl+f 搜尋 sleepinternal 卡住了多少個執行緒，截圖如下：
尼瑪，幾乎所有的執行緒都在休眠，一般來說，有這麼多執行緒在休眠也是少數，再畫個執行緒看看業務方法是怎麼休眠的，參考如下：
我發現這個迴圈方法中有很多睡眠（1），當我看到這個時，我突然想到了高頻上下文切換導致的CPU爆炸。
此**指令接下來停止在哪種方法？您可以反編譯 loop 方法。
0:047> !clrstackos thread id: 0xad8 (47)child sp ip call site20b5f434 77dd19dc [helpermethodframe: 20b5f434] system.threading.thread.sleepinternal(int32)20b5f4a0 141975f4 system.threading.thread.sleep(int32) [/_/src/libraries/system.private.corelib/src/system/threading/thread.cs @ 357]20b5f4b4 1f123c71 xxx.actionthread`1[[xxx].loop()20b5f698 74467741 system.threading.thread+starthelper.callback(system.object) [/_/src/libraries/system.private.corelib/src/system/threading/thread.cs @ 42]20b5f6a8 1baab7da system.threading.executioncontext.runinternal(system.threading.executioncontext, system.threading.contextcallback, system.object) [/_/src/libraries/system.private.corelib/src/system/threading/executioncontext.cs @ 183]20b5f6e0 74466742 system.threading.thread.startcallback() /_/src/coreclr/system.private.corelib/src/system/threading/thread.coreclr.cs @ 105]20b5f834 74cbc29f [debuggeru2mcatchhandlerframe: 20b5f834] 0:047> !u /d 1f123c71normal jit generated codexxx.actionthread`1[xxx].loop()iladdr is 0a324040 pimport is 08ad6468begin 1f123c10, size abd1f123c10 55 push ebp1f123c11 8bec mov ebp,esp1f123c13 57 push edi1f123c14 56 push esi1f123c15 81ecd4010000 sub esp,1d4h1f123c1b c5f877 vzeroupper1f123c1e c5d857e4 vxorps xmm4,xmm4,xmm41f123c22 c5fa7fa524feffff vmovdqu xmmword ptr [ebp-1dch],xmm41f123c2a c5fa7fa534feffff vmovdqu xmmword ptr [ebp-1cch],xmm41f123c32 b850feffff mov eax,0fffffe50h1f123c37 c5fa7f6405f4 vmovdqu xmmword ptr [ebp+eax-0ch],xmm41f123c3d c5fa7f640504 vmovdqu xmmword ptr [ebp+eax+4],xmm41f123c43 c5fa7f640514 vmovdqu xmmword ptr [ebp+eax+14h],xmm41f123c49 83c030 add eax,30h...1f123c5a e84115cc55 call coreclr!jit_dbgisjustmycode (74de51a0)1f123c5f 90 nop1f123c60 90 nop1f123c61 e9300a0000 jmp xxx.actionthread.loop+0xa86 (1f124696)1f123c66 90 nop1f123c67 b901000000 mov ecx,11f123c6c e87f54eaea call 09fc90f0 (system.threading.thread.sleep(int32), mdtoken: 06002d01)>>1f123c71 90 nop...在 sleep（1） 中會有乙個 CPU 的等待佇列、乙個就緒佇列和乙個 timer ktimer 核心物件，因為 Windows 原始碼不是公開的，所以內部還是比較有趣的，你可以使用 ！PCR 命令觀察 CPU 的背包。
lkd> !pcr 0kpcr for processor 0 at fffff8058023c000: major 1 minor 1 nttib.exceptionlist: fffff80589089fb0 nttib.stackbase: fffff80589088000 nttib.stacklimit: 000000137e1fa158 nttib.subsystemtib: fffff8058023c000 nttib.version: 000000008023c180 nttib.userpointer: fffff8058023c870 nttib.selftib: 000000137dfe0000 selfpcr: 0000000000000000 prcb: fffff8058023c180 irql: 0000000000000000 ..currentthread: ffff910c66906080 nextthread: 0000000000000000 idlethread: fffff80583d27a00 dpcqueue: lkd> dt nt!_kprcb fffff8058023c180 +0x008 currentthread : 0xffff910c`66906080 _kthread +0x010 nextthread : null) +0x018 idlethread : 0xfffff805`83d27a00 _kthread ..0x7c00 waitlisthead : list_entry [ 0xffff910c`5ec30158 - 0xffff910c`628b1158 ] 0x7c80 dispatcherreadylisthead : 32] _list_entry [ 0xfffff805`80243e00 - 0xfffff805`80243e00 ]有了上面的分析結果，最後就是告訴你的朋友做以下兩件事：
減少執行緒sleep（1） 的執行緒參與數。 盡量用1->50來緩解，當然越大越好。 這次CPU爆裂還是挺有意思的，不是業務方式導致的爆裂，而是睡眠（1）導致的大量高頻上下文切換，有點意思，留下這篇文章給大家避坑！