这个工具退出来很有一段时间了！之前一直没有体会到它的威力。直到最近遇到一个问题！

测试反馈一个挺重要服务（登录服务）死了！

经过排查发现是因为mysql连接数到达100（在mysql上使用语句： show full processlist 发现全是状态为sleep的连接），没法接受新的连接导致，重启服务，连接数归0，暂时解决问题！当然这绝对不是最终的解决方案。

经过观察发现数据库sleep的连接只要业务操作一次，就增长一个，连续操作100次，那就超出数量限制，接下来就拒绝服务了。

这个服务连接mysql使用的是ef(Pomelo.EntityFrameworkCore.MySql (2.1.1))。

登陆服务使用的是IdentityServer4来实现的。使用到的包：IdentityServer4.EntityFramework

一开始根本没什么头绪，估计问题要么出在EF上，要么出现在IdentityServer4.EntityFramework上

我先把问题定位在IdentityServer4.EntityFramework。从github上clone下源码，分析发现只需要实现几个接口就行，然后就自己去实现了接口，接口是下面几个：

一起四个，我不用ef去实现，而改用其他方式（估计没问题）。修改，部署到开发环境，问题依旧。IdentityServer4.EntityFramework的嫌疑排除。

到目前为止已经花费了比较多的时间了，之后我还自己测试了Pomelo.EntityFrameworkCore.MySql，并不会因为多次使用而出现占用多个mysql连接的问题。

一度曾经把怀疑的目标放在ef上。

最后静下心来发现这样弄，恐怕方向错了！要是这样一个一个排查，恐怕需要花费极多的精力，问题也不一定能解决！

最后自己使用了一些工具来帮助自己，其实经过分析，我基本已经把问题定位在EF的DbCOntext上了，但是目前已知的DbContext，也就是IdentityServer4.EntityFramework上的两个已经排除了嫌疑。难道还有其他我没有注意到的DbContext？

接下来就是vs2017上面的诊断工具出场了。

我用vs2017启动程序。

然后操作一次登录，然后切换到诊断工具，截取一次内存快照，效果如下：

 

然后进行第二次，内存快照的截取。

 

点击第一个红色向上箭头左边的连接，打开了一个窗口查看新增的对象，可以确定这里一定有一个新增的占用mysql连接的DbContex

搜索类型名：DbContext

果然出来一个，其实到了这一步，定位到出现问题的DbContext,问题基本解决！

最后问题是出在一段手动使用EF事务的代码上，之后改变了使用方式，问题解决。

一开始以为问题是在EF上，其实不是。

通过这件事我认识到，这个之前我一直不怎么关注的工具的威力，下次出现问题，我会优先使用它来进行分析