分析.NET Dump原来这么简单，你也快来试试吧！

我相信，只要代码写到足够多的时候，就肯定会遇到足够的BUG和难题，常见有错误日志的还是比较简单的，最让人头疼的就是OOM，内存溢出，各种重启，内存居高不下等等疑难杂症。 今天正好看到一篇文章说到了分析dump的，流程很简单，今天用BlogCore项目给大家分享下过程，全程看完只需要五分钟，自己动手只需要十分钟，十五分钟后，分析.net内存爆炸问题，你就入门了。今天演示的是在win10本地，在其他OS平台上是一样的。

现在，我们运行任意ASP.NetCore项目，这里用BlogCore举例，启动好后，噼里啪啦一顿点击操作，然后就开始了今天的故事。

1、安装dump工具

dotnet tool install --global dotnet-dump

很简单，直接执行这句命令就行了。当然，本地也是需要安装sdk的，没有sdk也不太好运行项目。

2、收集dump文件

项目启动后，一顿操作，就是为了触发系统运行所带来的各种情况，比如内存的变化，GC的处理等等。

先查看我们项目端口所在的PID

netstat -ano | findstr "LISTENING" | findstr ":9291"

然后开始收集

dotnet-dump collect -p 19524

这个时候，就会看到dmp文件就出现了

3、分析dump文件

现在到了重头戏，有了dmp文件，开始分析了。

dotnet dump analyze c:\xx\x\xxxx.dmp

现在进入分析流程，先查一下GC堆栈信息

eeheap -gc

可以清晰地看到有几个GC堆，可以对大小进行过滤，比如说只看1M以上的

dumpheap -stat -min 1024000

这里显示，一共有两个objects，一共才3M多，这完全没有看的必要。 同时也能证明，BlogCore启动的时候，就是比较轻量，没啥大内存。

4、手动内存爆炸

为了达到很好的分析效果，咱们在BlogCore的登录接口，随便写个死循环，大内存的往里灌试试。

启动项目，一顿操作，访问这个api接口，看到内存瞬间就炸了，1.7G，还一直在GC，这下子有用了。

还是重复第三步的内容，生成dmp文件，分析dmp文件，查看GC堆，

这下很直观了，一共五个超过1M的，共524M左右，类是Byte数组，聪明的你是不是已经发现了其中猫腻

继续操作，找字节数组都有哪些

dumpheap -type System.Byte[]

随便找一个比较大的，就是这个027ad4c00048，看一下这个对象

dumpobj 027ad4c00048

没看到很明显的东西，再执行命令，查看引用情况

gcroot 027ad4c00048

可以看到具体的Thread号和引用地址，是不是一目了然，我相信看到这里，基本上就能猜出来七七八八了吧，毕竟地址都给你了，就是LoginController的GetJwtToken3方法。

当然，也可以看看具体这个线程对应的线程数，用threads命令即可

看到了这里，基本已经破案了，

打完收工，建议大家动手练习起来，为以后储备技术栈，当然还有更高级的玩法，有想学或者想了解的，欢迎下边评论。

参考文章： https://www.cnblogs.com/myzony/p/18061108/troubleshooting-memory-surge-issues-in-dotnet-core-applications