0:198> !tpCPU utilization: 100%Worker Thread: Total: 197 Running: 42 Idle: 154 MaxLimit: 32767 MinLimit: 8Work Request in Queue: 0--------------------------------------Number of Timers: 0--------------------------------------Completion Port Thread:Total: 10 Free: 5 MaxFree: 16 CurrentLimit: 10 MaxLimit: 1000 MinLimit: 8
从卦中信息看当前 CPU=100%，还是蛮惨的，那到底谁在吃CPU资源呢？根据履历先查一下是不是触发了2代GC，接下来用 !t 不雅观察下是否有GC标记。
0:198> !tThreadCount: 214UnstartedThread: 0BackgroundThread: 211PendingThread: 0DeadThread: 1Hosted Runtime: no Lock ID OSID ThreadOBJ State GC Mode GC Alloc Context Domain Count Apt Exception0 1 276f0 000002789526b5f0 2a020 Preemptive 0000000000000000:0000000000000000 000002789525e840 0 MTA 2 2 25e5c 0000027895296d00 2b220 Preemptive 0000000000000000:0000000000000000 000002789525e840 0 MTA (Finalizer) 3 3 260e8 00000278ae35f0c0 202b020 Preemptive 0000000000000000:0000000000000000 000002789525e840 0 MTA ...169 2113 10c20 00000278c26766c0 1029220 Preemptive 00000278B5D7D188:00000278B5D7D188 000002789525e840 1 MTA (GC) (Threadpool Worker) xxxException 00000278b5d46ce0 ...
尼玛从卦中的 (GC) 来看，还真的触发了GC，接下来的研究方向便是洞察下是不是CPU爆高的罪魁。
要探求这个问题的答案，首先便是看下这次GC是不是 FullGC 即可，可以切到 169 号线程，不雅观察下线程栈。
0:169> k 10# Child-SP RetAddr Call Site00 000000c4`36ffb798 00007ffc`d5f14313 ntdll!NtWaitForSingleObject+0x1401 000000c4`36ffb7a0 00007ffc`c927cb27 KERNELBASE!WaitForSingleObjectEx+0x9302 000000c4`36ffb840 00007ffc`c927cadf clr!CLREventWaitHelper2+0x3c03 000000c4`36ffb880 00007ffc`c927ca5c clr!CLREventWaitHelper+0x1f04 000000c4`36ffb8e0 00007ffc`c926bd32 clr!CLREventBase::WaitEx+0x7c05 000000c4`36ffb970 00007ffc`c9269bc4 clr!ThreadSuspend::SuspendRuntime+0x32c06 000000c4`36ffba60 00007ffc`c91814e3 clr!ThreadSuspend::SuspendEE+0x12807 000000c4`36ffbb60 00007ffc`c9185f51 clr!WKS::GCHeap::GarbageCollectGeneration+0xb708 000000c4`36ffbbc0 00007ffc`c9260f56 clr!WKS::gc_heap::trigger_gc_for_alloc+0x2d09 000000c4`36ffbc00 00007ffc`c6b0f7e7 clr!JIT_NewArr1+0xa970a 000000c4`36ffc030 00007ffc`6a388270 mscorlib_ni!System.String.ToCharArray+0x27 [f:\dd\ndp\clr\src\BCL\system\string.cs @ 758] 0b 000000c4`36ffc080 00007ffc`6a3880ed 0x00007ffc`6a3882700c 000000c4`36ffc100 00007ffc`6a56056d 0x00007ffc`6a3880ed0d 000000c4`36ffc150 00007ffc`6a3cd749 0x00007ffc`6a56056d0e 000000c4`36ffc1b0 00007ffc`c911989d 0x00007ffc`6a3cd7490f 000000c4`36ffc220 00007ffc`c9119764 clr!ExceptionTracker::CallHandler+0xfd
从卦中看此时的GC还处于早期的 SuspendEE 阶段，无法获取内部的 settings 构造，这就比较麻烦了，那怎么办呢？只能看看 GarbageCollectGeneration 的第一个参数有没有保存在栈中，假如没有就惨了。。。方法署名如下：
size_tGCHeap::GarbageCollectGeneration (unsigned int gen, gc_reason reason){}
根据 x64调用协定，gen是保存在 rdx 寄存器里，接下来不雅观察汇编代码。
0:000> uf 00007ffc`c91814e3clr!WKS::GCHeap::GarbageCollectGeneration:00007ffc`c918142c 48895c2418 mov qword ptr [rsp+18h],rbx00007ffc`c9181431 89542410 mov dword ptr [rsp+10h],edx00007ffc`c9181435 48894c2408 mov qword ptr [rsp+8],rcx00007ffc`c918143a 55 push rbp00007ffc`c918143b 56 push rsi00007ffc`c918143c 57 push rdi00007ffc`c918143d 4154 push r1200007ffc`c918143f 4155 push r1300007ffc`c9181441 4156 push r1400007ffc`c9181443 4157 push r15...0:169> dd 000000c4`36ffbbc0-0x8+0x10 L1000000c4`36ffbbc8 00000000
从卦中看，谢天谢地，edx保存在 rsp+10h 的位置，通过dp不雅观察内存地址的值创造是0，也就表示当前是 0 代GC，这种smallgc 常常触发是很正常的，并不是我们CPU爆高的诱因，接下来就陷入迷茫了。。。
撞了南墙之后得要看看其他路子，实在刚才用 !t 不雅观察线程列表的时候我就把稳到一个特色，那便是很多线程上挂了非常，截图如下：
从卦中看此时有19个线程在抛 xxxResultException 非常，做过开拓的朋友都知道，如果频繁的抛非常是很耗CPU资源的，由于它要设计到用户态到内核态的切换，如果有 19 个线程一起抛非常，那绝对是一个灾害。。。
有些朋友说我cpu猛一点是不是就可以了，哈哈，理论上是可以的，可以用 !cpuid 不雅观察下这台机器的cpu核心数。
0:169> !cpuidCP F/M/S Manufacturer MHz0 6,167,1 <unavailable> 34081 6,167,1 <unavailable> 34082 6,167,1 <unavailable> 34083 6,167,1 <unavailable> 34084 6,167,1 <unavailable> 34085 6,167,1 <unavailable> 34086 6,167,1 <unavailable> 34087 6,167,1 <unavailable> 3408
从证据链的完全性上来说，实在这里还须要再做一个验证，便是19个线程抛非常不代表他们的并发性，言外之意便是能不能再找一些其他证据，怎么找其他证据呢？
做C#开拓的朋友该当知道，Exception 属于引用类型，如果密集抛了很多非常，那托管堆上自然就有很多，直到GC回收，以是我们不雅观察下这个韶光差即可，利用 !wdae 命令，这里为了隐私性我就模糊了哈。
0:169> !wdae384 of Type: xxxResultException 000002789fdb6478 000002789fdb69b0 000002789fdb9848Message: xxxFailedInner Exception: (none)Stack:IP Function00007ffc6a269861 xxx.ChannelAsyncOperation`1[[System.Int32, mscorlib]].End(Int32, Boolean)...411 of Type: xxxResultException 000002789fdb6e90 000002789fdb7090 000002789fdb72a8Message: xxxClosedInner Exception: (none)Stack:IP Function00007ffc6a269861 xxx.ChannelAsyncOperation`1[[System.Int32, mscorlib]].End(Int32, Boolean)...808 Exceptions in 12 unique type/stack combinations (duplicate types in similar stacks may be rethrows)
从卦中看当前抛了808个非常，大多是和channel通信有关，结合16个线程并发抛，这就稳了，看样子cpu爆高期间便是由于高频的抛非常所致，剖析出这些信息之后，便是见告朋友把这些非常给办理掉即可。
三：总结CPU爆高的诱因非常多，高频的抛非常就属于个中一例，实在这种通信时发生了突发非常正是 Polly 这种 弹性和瞬态故障处理库 大显技艺的地方。
