專案上線以來一直存在一個比較揪心的問題，和一個沒有信心處理的BUG，那就是在應用程式啟動時有可能會導致cpu跑滿99%或持續在一個值如50%左右，這樣一來對伺服器的壓力是非常大的，經常出現伺服器無法遠端的狀態，唯有通過PowerShell殺掉對應的w3wp程式才可以解決這個問題。
為什麼沒有信心處理這個問題
原因非常簡單，這個問題是間歇性的，不容易重現的，只會在專案啟動時有一定的可能性會發生CPU跑滿的問題。
所有可以重現的BUG的處理都不會太難，而類似這種無法重現的BUG是最讓人頭疼的，因為它無影無蹤，令人難以尋跡。
如何處理這個問題？
1.一開始採用猜的辦法，去專案中找while、lock等關鍵詞，這樣無異於大海撈針，而且不嚴謹的修改還會導致其他更為嚴重的問題產生，很快這個方案在搜尋過一遍後被放棄了。
2.後來記得有用過WinDbg解決過電腦藍屏的問題，就猜想是否可以抓取對應w3wp程式的dump進行分析。
使用WinDbg查詢線索
1.由於伺服器是2008R2抓取dump就變得異常簡單。
2.使用WinDbg
load SOS.dll後檢視執行緒資訊。
發現有7個執行緒比較耗時，這時候心想我用的執行緒也是7個，這時候內心無比的激動。
切換到21執行緒，檢視堆疊資訊後發現
在Dictionary的Insert時堵塞了，這時候檢視其它佔時很長的執行緒狀態，也不外乎是這裡堵塞了。
Dictionary中的Insert方法真的會堵塞嗎？
寫下如下測試程式碼後執行了幾次
發現真的在有些時候cpu會佔的非常高有時候又正常。
那麼問題也就明朗了，解決它也變得非常容易，找到GetRoutes程式碼，原先是這麼實現的
BundleTable.Bundles內部維護了一個靜態字典表，那麼問題就呼之欲出了，對這段程式碼加鎖。
修改後的程式碼
觀測了一段時間後，問題也確實解決了。
Dictionary中的Insert為什麼會堵塞
我知道Dictionary不是一個執行緒安全的型別，但我原本以為Dictionary在非執行緒安全方式下訪問時資料會錯亂，而不會堵塞或者死鎖，而這次的這個問題讓我感覺到訝異，為什麼Add一個專案會造成堵塞？
反編譯Dictionary的原始碼後發現異常的複雜，也沒有細究，所以下面的一段描述大家抱有自己的想法去閱讀，可能是錯的也可能是對的。
上面是我認為存在問題的地方，當一個執行緒執行過Initialize後buckets陣列的值被修改，而第二個執行緒同時進入了Initialize方法，那麼第一個執行緒所維護的值被破壞，造成在演算法環節出現了死迴圈，這也可以說明了為什麼cpu有時候是50%有時候是99%的問題。
當前有多少個執行緒發生了這種狀態，如果發生這種狀態的執行緒越多則代表cpu佔用越多。
寫在最後
由於一開始不會使用WinDbg找了技術群裡的StevenChen幫忙解決問題，巧合的是兩人推測出的問題在此相撞，在這裡感謝下StevenChen。
StevenChen也為此寫了一篇博文詳情請戳：http://www.cnblogs.com/StevenChennet/p/3991475.html