项目上线以来一直存在一个比较揪心的问题，和一个没有信心处理的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占用越多。