我相信，只要代码写到足够多的时候，就肯定会遇到足够的BUG和难题，常见有错误日志的还是比较简单的，最让人头疼的就是OOM，内存溢出，各种重启，内存居高不下等等疑难杂症。
今天正好看到一篇文章说到了分析dump的，流程很简单，今天用BlogCore项目给大家分享下过程，全程看完只需要五分钟，自己动手只需要十分钟，十五分钟后，分析.net内存爆炸问题，你就入门了。今天演示的是在win10本地，在其他OS平台上是一样的。
现在，我们运行任意ASP.NetCore项目，这里用BlogCore举例，启动好后，噼里啪啦一顿点击操作，然后就开始了今天的故事。
dotnet tool install --global dotnet-dump很简单，直接执行这句命令就行了。当然，本地也是需要安装sdk的，没有sdk也不太好运行项目。
项目启动后，一顿操作，就是为了触发系统运行所带来的各种情况，比如内存的变化，GC的处理等等。
先查看我们项目端口所在的PID
netstat -ano | findstr "LISTENING" | findstr ":9291"然后开始收集
dotnet-dump collect -p 19524这个时候，就会看到dmp文件就出现了
现在到了重头戏，有了dmp文件，开始分析了。
dotnet dump analyze c:\xx\x\xxxx.dmp现在进入分析流程，先查一下GC堆栈信息
eeheap -gc可以清晰地看到有几个GC堆，可以对大小进行过滤，比如说只看1M以上的
dumpheap -stat -min 1024000这里显示，一共有两个objects，一共才3M多，这完全没有看的必要。
同时也能证明，BlogCore启动的时候，就是比较轻量，没啥大内存。
为了达到很好的分析效果，咱们在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
