1. 背景
在开发过程中,我们可能遇到应用程序线程占用过大的问题,可以通过windbg命令去定位哪些类型,哪些内存一直占用堆资源,从而查出问题,解决问题。
2. 准备工作
工具:
- 抓取DUMP文件的工具,任务管理器(最简单),DebugDiag,ProcessExplorer等(网上很多)
- 分析工具windbg
PS:使用任务管理器的时候需要强调一下如何抓包:根据你的进程是多少位的,然后使用对应位数的任务管理器去抓,
不然抓到的DUMP文件是无效的。
如果在下面分析过程中出现“SOS does not support the current target architecture”这样的错误,就是使用了64位的
任务管理器导出了32位进程的dump文件,下面是两个解决方法:
(1)使用32位任务管理器,运行:C:WindowsSysWOW64 askmgr.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这个工具真的很锻炼人,慢慢从头学起吧!与君共勉~