前些天接前方反馈，线上升级后，IIS CPU爆高，已影响用户使用体验，遂指导现场运维赶紧dump一份内存，
老夫也将分析过程，分享如下，如有不正的，欢迎分享讨论
好久没发帖了。
windbg sos使用就不写了，网上已有大量教程。
运维发来截图 IIS CPU爆高

windbg走起：
使用!tp
如下图CPU 96%，且还有8个等待cpu调度的任务，已出现任务堆积现象，说明此时CPU已相当繁忙。


16核心CPU基本全部爆满。
使用PerfView对dump进行火焰图分析如下，可见大量占用时间片较多的基本是Newtonsoft.Json


CPU高无外乎几种可能：锁（死锁、以及.net中大量其他锁类型，如：SyncBlock、ReaderWriter等）、GC、以及死循环，下面将逐一进行排查。
1、查看同步块表如下：

从同步块表的卦象上看，正常，故可以排出存在由于线程同步导致的死锁引发的cpu爆高问题。
2、查看GC，如下：有线程此时处于GC状态


如上图可见，有线程处于GC

再使用x clr!gc_heap::settings，在内存检索关键字，查看
由于线上.net设置是服务器模式，故查看第二个
根据结构gc_heap::settings与枚举gc_reason对照
从上图上看，有GC处于2代回收，回收原因为4（大对象分配），从下图也统计也可看出，在有10个线程上存在大对象分配操作，导致GC触发。这也是导致CPU高的其中一个原因（后续分析）。

3、既然同步块表中无锁等待，使用!mlocks命令再次查看其它锁类型，如下：存在大量thinlock锁

统计存在1023个thinlock锁
使用!gcroot随便抽一个查看lock对象引用根，如下图，基本上来自于System.Collections.Generic.Dictionary

使用命令：~*e!dumpstack 查看所有线程栈，在栈上搜索该方法对象，存在23次调用，如下图：

在托管堆上搜索该对象统计，如下图：
使用命令：!dumpheap -live -min 8196 -type System.Collections.Generic.Dictionary

如上图可知，托管堆上有较多此类对象，还有较大的这类对象。
抽一个较大对象，查看其引用根，如下图

由图可知，最终这类lock对象来自于System.Collections.Generic.Dictionary中的table操作，由json序列化引发。
使用命令!mdt展开查看table对象，如下，由图可知，这里存在1024个lock对象，以及3w+个元素。

其引用来自json序列化，与前面火焰图分析一致。

反编译如下：


如上图在json序列化中，用到的table确实被上锁。

在前面分析我们提到有GC进行回收操作，且为大对象分配，接下来分析下大对象操作，
1、使用命令!dumpheap -stat查看所有托管堆状态，如下图：

从此卦象来看，首榜为string对象
2、再使用!dumpheap -live -min 8196 -mt 来查看String方法表中>8196的对象信息，.net将>8196的对象定义为大对象，如下图
还不少

3、随便挑一个较大的使用!do来查看对象信息

从老夫选取的几个来看基本上是json字符串，几百KB到1MB+不等。

[培训]内核驱动高级班，冲击BAT一流互联网大厂工作，每周日13:00-18:00直播授课