背景 最近一位朋友找到我，讓我幫看他們的一個aspnet core service無端cpu高的問題。從描述上看，這個service之前沒有出現過cpu高的情況，最近也沒有改過實際的什麼code。很奇怪了，會有什麼變化導致cpu上去了呢？ 分析 由於比較容易復現 (據說一啟動service，cpu就 ...
背景
最近一位朋友找到我，讓我幫看他們的一個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更貼切吧?
