继上次记一次w3wp占用CPU过高的解决过程（Dictionary和线程安全）后又再次与Dictionary博弈，这一次是在EntityFramework中的Dictionary。

从一个异常说起

这个异常与上次的异常有着同一个特性：间歇性，碰到类似的异常在信心上就被削弱了一大半。。。

在第一次看到这个异常的时候觉得解决它非常的简单，无非就是在字典操作的地方加个锁，但仔细看了一会发现这个问题并没有那么简单，可以看到这个异常的最后几个堆栈信息来自System.Data.Entity命名空间，也就是EntityFramework，这就使问题变得难以寻纠。

出错的地方就在FirstOrDefault，一个在简单不过的Linq方法。

反编译查看EntityFramework的实现

AddNewRelation方法的内容如下：

马上锁定了AddRelationshipEntryToDictionary，方法代码如下：

可以看出是EntityFramework添加状态监控相关的逻辑，看到这也大概猜出来了又是线程安全的问题，但为了确定我追纠了调用AddNewRelation的HandleRelationshipSpan方法。

代码比较复杂，较难看懂，于是就去EntityFramework源码托管的站上面去看看是否有写注释，碰碰运气。

果不其然还是存在比较详尽的注释

问题也大致清晰了，应该是线程共享的DbContext出现了问题。

用Demo还原异常

解决方案

因为我们并不想放弃线程内共享一个DbContext的方案，所以我们并没有从根本解决这个问题，我们把调用FirstOrDefault的操作放在了Lazy里面。

剩下的就是观察效果。

写在最后

写了两篇解决BUG的纪要不为了大家能快速解决问题，而为了交流一种寻找BUG解决BUG的思路与方法。

最后，福州地区有需要找工作或者想换工作的“猿”吗？如果有可以沟通沟通联系联系呗。

EntityFramework中的线程安全，又是Dictionary