背景
某天晚上八点多，突然收到一个 CPU 爆表的告警。
过了一会，几个业务线就开始反馈系统变慢了。
后面紧急处理了这台机器后，让业务先恢复正常。
后续看了一下监控，拔凉拔凉的。
这个服务是比较重要的一个老业务，.NET Framework 的 Web API 项目。
回过头来看一下，要找出造成了 CPU 持续 100% 的根本原因，这样才能把这个雷去掉。
要分析的话，需要创建了一个 CPU 持续很高的时候的 dump 包，然后用 WinDbg 来处理。
下面来分析一下，探个究竟。
WinDbg 分析
WinDbg分析CPU，用的比较多的其实就那几个命令。
照着走一遍基本就出来结果了。
首先是用 !threadpool 查看当前CPU状况和线程信息。
上面主要的是 76% 的 CPU 使用率。
然后是用 !runaway 看线程的耗时，看那个占用多
从上图可以看出 32 、34 、38 、39 这几个线程比较可疑。
下面就是切换到对应的线程看具体的信息了。
用 ~34s 切换到 34 号线程，如果是其他，按需替换即可。
然后用 !clrstack 看这个线程在执行什么内容
上面的图很清晰的告诉我们，有一个 ConverAgeMonth 的方法，里面用到了正则。说到正则，用的不好，真的很容易出问题。
到这里基本就知道问题出在那里了。
下面还要看具体的参数信息，才会更加清晰一点。
这里用的是 !clrstack -p 这个命令。
可以看到 ConverAgeMonth 这个方法有两个参数， age 和 ageMonth。
点一下 age 对应的地址或者手动输入 !do 地址 就可以看到具体的字符串内容了。
看到这个超级长字符串，长度接近 2w 。。。。
同样看了其他几个，都是如出一辙，可以断定就是那个正则惹的祸了。
后续调整了这一块的内容后就没有出现过了 CPU 爆表的情况了。
写在最后
虽然 WinDbg 用起来感觉很不错，不过整体流程相对复杂一点，相当于是离线分析，不能实时进行观测和分析。
这一块还有待完善，有很大的提升空间。
