w3wp占用CPU过高
在此之前项目有发生过两次类似的状况，都得以解决，但最近又会发现偶尔CPU会跑满，虽然之前使用过WinDbg解决过两次问题但人的记忆是不可靠的，今天处理同样问题的时候还是遇到了一些障碍，这一次希望可以记录的更全面些。
上两次的博文链接：记一次w3wp占用CPU过高的解决过程（Dictionary和线程安全）、EntityFramework中的线程安全，又是Dictionary。
首先请大家不要喷我，因为这一次还是关于Dictionary的一些低级错误，我自己看到都无语了。。。
抓取Dump
使用任务管理器抓取Dump，如果操作系统较低可以使用“Process Explorer”。
使用WinDbg分析
1.使用WinDbg打开dump文件。
2.加载sos.dll
命令：.loadby sos clr
3.查看相关线程信息
命令：!threads –special
special参数会将由CLR创建的特殊线程单独列出便于减少线程的排查工作。
红框圈出的是我们要重点排查的线程（工作者线程），至于其它的则是一些CLR自拥有的一些线程，如：GC线程、对象释放线程、计时器线程、I/O线程等。
线程类型的名称翻译：
- GC:垃圾回收线程
- Finalizer:对象释放线程，.Net至少有一个，用于专门处理对象释放。
- Timer：计时器线程
- ThreadpoolWorker：工作者线程
- IOCompletion：I/O线程
4.查看具体线程堆栈
命令：~{ThreadId}s、!clrstack
~{ThreadId}s：将当前上下文切换到指定的线程内
!clrstack：得到当前的线程的堆栈信息
第二个红框的前两句太长了，我复制在下面：
000000d784afe180 000007fda1efa328 System.Collections.Generic.Dictionary`2[[System.__Canon, mscorlib],[System.Collections.Generic.KeyValuePair`2[[System.__Canon, mscorlib],[System.Boolean, mscorlib]], mscorlib]].FindEntry(System.__Canon)
000000d784afe1f0 000007fda1ef96eb System.Collections.Generic.Dictionary`2[[System.__Canon, mscorlib],[System.Collections.Generic.KeyValuePair`2[[System.__Canon, mscorlib],[System.Boolean, mscorlib]], mscorlib]].TryGetValue(System.__Canon, System.Collections.Generic.KeyValuePair`2<System.__Canon,Boolean> ByRef)
可以发现，是在TryGetValue方法时堵塞了，而看到红框中的最后一句则可以发现是EnumParseCacheHelper的Parse方法出了问题，这个方法主要是对枚举转换的一个缓存处理以提升性能。
为了再次确认问题，我继续对19、20、21、24等线程进行了查看，都是在这里堵塞了，那么问题浮出水面了，下面就去看代码，并且解决它。
解决问题
找到对应的代码：
问题显而易见，CacheDictionary是一个全局静态的字段，而我在下面方法使用它的时候丝毫没有注意并发下的情况，没有加锁来保证线程安全。。看到这感觉不可思议怎么犯这么低级的错误。。。
解决它方式：
解决方式很简单，使用了.NET4提供的线程安全的字典：ConcurrentDictionary。
关于这一次问题的思考
Dictionary为什么这么容易堵塞
这边引用之前的博文内容：
我知道Dictionary不是一个线程安全的类型，但我原本以为Dictionary在非线程安全方式下访问时数据会错乱，而不会堵塞或者死锁，而这次的这个问题让我感觉到讶异，为什么Add一个项目会造成堵塞？
反编译Dictionary的源码后发现异常的复杂，也没有细究，所以下面的一段描述大家抱有自己的想法去阅读，可能是错的也可能是对的。
上面是我认为存在问题的地方，当一个线程执行过Initialize后buckets数组的值被修改，而第二个线程同时进入了Initialize方法，那么第一个线程所维护的值被破坏，造成在算法环节出现了死循环，这也可以说明了为什么cpu有时候是50%有时候是99%的问题。
当前有多少个线程发生了这种状态，如果发生这种状态的线程越多则代表cpu占用越多。
这次问题的经验：以后在使用集合或字典时首先应该先想到System.Collections.Concurrent命名空间，虽然它的性能在正常情况下低于普通的Dictionary，但那么几十或者几百毫秒的损失对于稳定性来说微不足道，也减少了问题的发生。
写在最后
因为Rabbit.WeiXin是一个开源项目当然第一件事情就是发布更新。。避免更多的人出现此问题。
交流方式
QQ群：384413261（RabbitHub）
Email：majian159@live.com