又是经典的 CPU 爆高问题，到目前为止，对这种我还是有一些经验可循的。
- 抓 2-3 个 dump
第一个：有利于算两份 dump 中的线程时间差，从而推算最耗时线程。
第二个：有时候你抓的dump刚好线程都处理完了，cpu 还未真实回落，所以分析这种dump意义不大，我是吃了不少亏??????。
- 优先推测是否为 GC 捣鬼
现在的码农都精怪精怪的，基本不会傻傻的写出个死循环，绝大部分都是遇到某种 资源密集型 或 计算密集型 场景下导致非托管的 GC 出了问题。
好了，有了这个先入为主的思路，接下来就可以用 windbg 去占卜了。
二：windbg 分析
1. GC 捣鬼分析
GC 捣鬼的本质是 GC 出现了回收压力，尤其是对 大对象堆 的分配和释放，大家应该知道 大对象堆 采用的是链式管理法，不到万不得已 GC 都不敢回收它，所以在它上面的分配和释放都是一种 CPU密集型 操作，不信你可以去 StackOverflow 上搜搜 LOH 和 HighCPU 的关联关系??????。
2. 使用 x 命令搜索
在 windbg 中有一个快捷命令 x ，可用于在非托管堆上检索指定关键词，检索之前先看看这个 dump 是什么 Framework 版本，决定用什么关键词。
- 0:050> lmv
- start end module name
- 00b80000 00b88000 w3wp (pdb symbols) c:\mysymbols\w3wp.pdb\0CED8B2D5CB84AEB91307A0CE6BF528A1\w3wp.pdb
- Loaded symbol image file: w3wp.exe
- Image path: C:\Windows\SysWOW64\inetsrv\w3wp.exe
- Image name: w3wp.exe
- 71510000 71cc0000 clr (pdb symbols) c:\mysymbols\clr.pdb\9B2B2A02EC2D43899F87AC20F11B82DF2\clr.pdb
- Loaded symbol image file: clr.dll
- Image path: C:\Windows\Microsoft.NET\Framework\v4.0.30319\clr.dll
- Image name: clr.dll
- Browse all global symbols functions data
- Timestamp: Thu Sep 3 03:30:58 2020 (5F4FF2F2)
- CheckSum: 007AC92B
- ImageSize: 007B0000
- File version: 4.8.4261.0
- Product version: 4.0.30319.0
从 File version 上可以看出当前是基于 Net Framework 4.8 的，好了，用 x clr!SVR::gc_heap::trigger* 看看有没有触发 gc 的操作。
- 0:050> x clr!SVR::gc_heap::trigger*
- 71930401 clr!SVR::gc_heap::trigger_ephemeral_gc (protected: int __thiscall SVR::gc_heap::trigger_ephemeral_gc(enum gc_reason))
- 71665cf9 clr!SVR::gc_heap::trigger_gc_for_alloc (protected: void __thiscall SVR::gc_heap::trigger_gc_for_alloc(int,enum gc_reason,struct SVR::GCDebugSpinLock *,bool,enum SVR::msl_take_state))
- 71930a08 clr!SVR::gc_heap::trigger_full_compact_gc (protected: int __thiscall SVR::gc_heap::trigger_full_compact_gc(enum gc_reason,enum oom_reason *,bool))
从输出信息看，gc 果然在高速运转，开心哈，接下来看一下是哪一个线程触发了gc，可以用 !eestack 把所有线程的托管和非托管堆栈打出来。
