背景

最近一位朋友找到我，让我帮看他们的一个aspnet core service无端cpu高的问题。从描述上看，这个service之前没有出现过cpu高的情况，最近也没有改过实际的什么code。很奇怪了，会有什么变化导致cpu上去了呢？

分析

由于比较容易复现 (据说一启动service，cpu就上去了)，我便让那位朋友在cpu高的时候直接手动把.net进程dump了一下。于是就开始用windbg分析了

先看一下案发时进程中的线程情况，毕竟它们是让进程动起来的源泉哈。大部分线程都运行到如下类似位置（下面的callstack是虚拟化的，因为为了朋友的隐私，code已经虚拟化）：

这里可以看出有约38/2=19个线程运行到Services.CronJob+d__1.MoveNext这个位置。我又问了那位朋友，当时的运行环境是大约20个cpu core。真巧哈，几乎所有cpu core都很有可能跑到了这个地方了。

注：上面如何知道有38/2个线程，而不是38个线程呢？这是因为一般来说，当某个函数正在被调用时，callstack中会显示出两次，如图哈：

看到没，在"current frame"下面显示的上一层调用关系中会也显示这个方法，此时它是callee哈。

那么这个Services.CronJob+d__1.MoveNext是何方神圣呢，名字叫cpu killer更贴切吧?