1. 背景

在开发过程中，我们可能遇到应用程序线程占用过大的问题，可以通过windbg命令去定位哪些类型，哪些内存一直占用堆资源，从而查出问题，解决问题。

2. 准备工作

工具：

• 抓取DUMP文件的工具，任务管理器（最简单），DebugDiag，ProcessExplorer等（网上很多）
• 分析工具windbg

PS：使用任务管理器的时候需要强调一下如何抓包：根据你的进程是多少位的，然后使用对应位数的任务管理器去抓，

不然抓到的DUMP文件是无效的。

如果在下面分析过程中出现“SOS does not support the current target architecture”这样的错误，就是使用了64位的

任务管理器导出了32位进程的dump文件，下面是两个解决方法：
（1）使用32位任务管理器，运行：C:\Windows\SysWOW64\taskmgr.exe。
（2）使用其它转储工具，比如：ProcessExplorer。

3. 分析

抓取DUMP文件后，使用windbg工具打开，首先加载SOS.dll，CLR.dll文件。

备注：SOS是啥东西？SOS可以调试扩展，让你可以查看在CLR里面运行的代码的有关信息。

例如，你可以使用SOS调试扩展显示托管堆的有关信息，查找堆的错误，显示运行时使用的内部数据类型，

以及查看在运行时里面运行的所有托管代码的有关信息。

相关参考：https://www.cnblogs.com/ceachy/p/WinDBG_SOS.html

备注：以上加载sos.dll与clr.dll的时候可能报错，上面截图的错误是说你使用的dll版本与当前的windbg分析的DUMP文件位数不一致

(1) 加载SOS&CLR

在加载sos.dll与clr.dll的时候，首先你要确定你的DUMP文件的位数，如果是32位则可以使用如下方式加载：

.load C:/Windows/Microsoft.NET/Framework/v4.0.30319/sos.dll
.load C:/Windows/Microsoft.NET/Framework/v4.0.30319/clr.dll

如果是64位，则使用另外的加载方式：

.load C:/Windows/Microsoft.NET/Framework64/v2.0.50727/sos.dll
.load C:/Windows/Microsoft.NET/Framework64/v4.0.30319/sos.dll

其中，SOS 的命令格式 ：![command] [options]

具体参考：https://www.cnblogs.com/kissdodog/p/3731743.html

(2)使用命令!dumpheap -stat 显示关于垃圾收集堆的信息和有关对象的收集统计：

图3-1

图3-2

以上命令执行后，输出结果的第一列是mt（method table）信息，表示类型对象的地址，我们可以使用此信息来明确指定我们感兴趣的对象在堆中的信息。

看到上面的数据，我们这些占用内存比较大的对象，此时有没有被引用？上面显示的是所有堆的整体占用信息，其实我们比较关心的还是被引用的对象的信息。

使用命令：!dumpheap -dead -min 85000  参数 -dead：表示仅输出没有没有被引用的对象 （这些对象将在下一个 Full GC 中被回收）；

-min 85000 ：表示查看大于85000bytes字节的对象

命令执行后发现：00000004b06ad190（占用48M）与00000004802fef20（占用49M）这两个对象都没有被引用了（挑了两个占用大的），那么 这些对象将在下一个Full GC中被回收。

相反，使用命令：!dumpheap -live -min 85000 查看的是还被引用的对象：

根据分析结果可以看出，占用比较大的是0000000484884750（占用24M），我们使用命令：!do 0000000484884750 

查看一下这个对象到底是何方妖孽：

上图的结果显示：其中占24M的数据对象，发现竟然是log的存储，天了噜！

这样不行，从图3-1中，再挑选一个业务性比较强的类型看看。

场景1：

选择查看StaffDto数据，首先还是执行命令：!DumpHeap -mt 000007fe9ba5eba0 查看显示有关垃圾收集堆和收集站的信息

以上命令输出第一列是Address，表示具体数据的地址，从上面可以看到这个StaffDto对象共有58515个，然后占堆内存30M，拿其中某一个看看

!dumpobj 000000038a71b7f0

打印EEClass结构，其中可以看到类型静态变量信息，可以根据MT信息查询其中的字段信息

看看里面的字段吧，!do 000000038a71ba60 （Email）

然后输入命令：!gcroot 000000038a71ba60（!gcroot 命令是用来查看其中某一个对象的引用根信息），看看其引用根：

我晕，竟然没有引用根。

备注：!gcroot是一个非常有用的命令，它能够帮助我们发现某对象上目前还存在的有效引用，这也是为什么GC还不回收这个对象的原因。

这个信息可以很好的帮助我们分析那些本应该没有引用，但却一直还存在有效引用的对象，

由此发现我们代码中潜在的内存泄漏，同时我们也可以观察到哪些对象是目前没有引用了。

场景2：

我们选择图3-2中最后那个string类型的对象数据：

!dumpheap -mt 000007fef828da88

结果分析发现：string类型的数据个数180W，占用222M内存，这也不用大惊小怪，代码程序中使用频繁的对象应该就是string了，接着往下看。

!dumpheap -mt 000007fef828da88 -min 85000 // 查看85K以上的string类型数据

命令执行结果显示：大于85K的string对象有8个，占98M，其中两个分别是42M与48M

那就重点观察这两个string类型的对象，使用命令

!dumpobj 00000004b06ad190 （等价于!do）

然后紧接着去分析这个对象的引用根信息，输入命令：!groot 00000004b06ad190 

这个对象竟然也没有有效引用根？？？

看看这个对象内容吧，使用命令：dc 00000004b06ad190 L1000（命令dc是查看对象内容，参数L代表显示多少行）

以上结果显示，这个48M的string内容是存的staffDto信息。

以上就是我根据网上的教程，然后拿着自己在服务器dump下来的文件进行的内存分析，windbg这个工具真的很锻炼人，慢慢从头学起吧！与君共勉~