前言：

對于需要長時間運行的.net程序，有時需要我們查看內(nèi)存的使用有沒有內(nèi)存泄露問題。

我們可以從dump文件中找到答案。 

Dump的看點

用dump文件來分析內(nèi)存，到底我們需要關(guān)心哪些點呢？

1. 內(nèi)存的使用情況 HeapSize/object的數(shù)量 也就是托管堆使用大小以及托管堆內(nèi)有多少數(shù)量的對象

　　　　1.1  查看有沒有存在有占用大量內(nèi)存的對象 <比如有某類下面的一個集合>

　　 　  1.2  0 1 2各代的size<查看各代的內(nèi)存是否有異常>

 

       2.調(diào)查是否有內(nèi)存泄露（重點）

　　　　2.1  查看object的根(Root) 看看GC回收不了的有哪些

　　　　2.2<我們知道一個對象Root下沒有引用就會標為可Gc對象,如果一個對象你希望被gc回收但寫代碼不注意又在別的地方保存了引用就會出現(xiàn)內(nèi)存泄露>

　　3.  終結(jié)器是否被阻塞時，當終結(jié)器線程被阻塞時，F(xiàn)inalize會等待累積(末尾有例子)

 

用什么工具

• Visual Studio
• DebugDiag
• WinDbg
• dotMemory(JetBrains旗下的 我還沒研究過)

以上三款是微軟給我們提供的工具,注意VS得要是Enterprise才可以哦。其他的兩款都是免費的。 

我們先寫一個sample程序

 

然后運行

  

  

一.用Visual Studio

打開dump文件

  

點擊按鈕 【調(diào)試托管內(nèi)存】

  

可以很清楚的看到有多少對象，每個對象共使用了多少內(nèi)存

在這個一覽下方有2個視圖 分別是

1.根的路徑

  

比如我們選擇 ConsoleApp2.B 這個對象

 

從這個圖可以看出來 B 這個對應 的 Paths To Root的追溯情況 (也就是構(gòu)建最終要GC的Root)

 Program._values(static變量) -> List<A> -> B

我們可以看到values就是B的Root 只要values不存在那B就會納入gc的回收對象中

因為我們是在Hold住了這個程序的main方法所以在這個時候B 對象還不能被gc回收

2.引用的類型

  

如何我們選擇List<ConsoleApp3.A>

那么就會展示List<ConsoleApp3.A>的引用關(guān)系如下圖所示：

  

從這個圖我們可以看出來 List<A> 持有 A[] ，A[]持有 A，A持有B

以上根據(jù)這2個視圖我們可以利用Vs來看出：

 咦？這個對象占用內(nèi)存怎么這么大 有點可疑

這個對象不是應該被gc嗎，怎么沒有被gc呢？研究下他的gc root看看

 

二.DebugDiag

下載地址 https://www.microsoft.com/en-us/download/details.aspx?id=49924 

  

點擊 【Add Data Files】 添加Dump文件后 點擊 【Start Analysis】 執(zhí)行

執(zhí)行成功后會自動用 IE 打開。

  

其實和 VS比起來差不多，直接生成一個報告也是比較方便的！ 

三.WinDbg

雖然使用上比較麻煩但是winDbg可以幫助我們分析的更加詳細

可以從微軟官方下載，為了方便百度云下載地址：

鏈接: https://pan.baidu.com/s/1eblPm4nuN0F-DkY_FzqUvA 提取碼: zmtd

注意要設(shè)置下Symbol Path

  

重新設(shè)置符號文件路徑如下；

SRV*C:\Symbols*http://msdl.microsoft.com/download/symbols

  

意思是如果在本地找不到則從微軟網(wǎng)站下載 

Ok設(shè)置完成后用WinDbg載入dump文件

  

如下圖所示：

  

打開成功后我們還不能開始分析必須

要先執(zhí)行加載SOS和CLR(對于.Net Runtime 4.0)

 【 !loadby sos clr】 命令

 

接下來我們用WinDbg來調(diào)查內(nèi)存使用情況：

一般我們定位內(nèi)存泄露問題，我總結(jié)的原則是要查到什么對象占用了大量內(nèi)存，為什么它沒有被GC。我們分以下幾個步驟

1.統(tǒng)計內(nèi)存中的對象&查找有異樣的對象

使用命令 【!DumpHeap -stat】

可以把堆中的對象類型和size給打印出來

 

我們可以看出來 A 和 B 是可疑對象

2.根據(jù)類型查找存活對象一覽

接下來我們根據(jù)查找出A的一覽

使用命令【!DumpHeap -live -mt <MT addr>】

 

結(jié)果如下：

 

可以看出內(nèi)存中A類型的對象有100000個

3.探索從某個對象找出GC ROOT一覽

使用命令【!GCRoot 】 

 

 

其實可以看出來和Visual Studio的【根的路徑】要點差不多吧。

 

WinDbg的其他常用命令

1. !DumpHeap -stat 查找托管堆按類型分組統(tǒng)計個數(shù)以及占用的總內(nèi)存大小

 

2.!HeapStat 查找當前堆中各代的內(nèi)存使用量 以及剩余使用量

 

3.!DumpHeap -live -mt <MT addr> 從MethodTable中查找存活的對象一覽

 

4.!DumpHeap -dead -mt <MT addr> 從MethodTable中查找要在下次FullGC要回收的一覽

 

5.!DumpMT -md <MT addr> 查看類型信息 （加了-md參數(shù)會把這個類型下的方法(MethodDescriptor)都打印出來）

 

6.!DumpClass <EEClass addr> 指定EEClass的地址

 

7.!Threads 查看Finalizer有沒有導致死鎖的例子

 

   如上圖所示， 用！Threads可以找出 Finalizer的線程為13.。接下來用命令 ~13k 查看線程執(zhí)行棧，

 

上圖是正常的情況沒有問題。執(zhí)行WaitForFinalizerEvent等下一次執(zhí)行信號

參考 https://github.com/dotnet/coreclr/blob/ca013149100a9ccc69a5df5b80f29fed2b1b0ce8/src/vm/finalizerthread.cpp#L571

 

 下圖是死鎖情況

  

可以看到有 CallFinalizer 和 FinalizeAllObjects 表示正在處理什么東西

在用命令【~[ID]e!clrstack】查看CLR的執(zhí)行棧情況

  

可以看出是在Finalize里面用了 Thread.Sleep導致的

 

 

使用SOSEX更方便的使用WinDbg

sosez是sos的擴展工具集(就是一個dll文件)，下載官網(wǎng)地址：http://www.stevestechspot.com/

下載完后要加載到 WinDbg里面去 使用命令 .load 進行加載

 

它集成了很多簡單使用的指令

例如： !mdt 可以根據(jù) 類型 進行篩選

 

 

藍色處可以直接點擊查看,功能很強大 

 

 

總結(jié)

.Net程序運行期間會遇到很多奇怪的問題，通過分許Dump文件分析內(nèi)存情況是一個很好的切入口。

不管用什么工具，按照以下幾個步驟：

• 統(tǒng)計內(nèi)存中的對象
• 查找有異樣的對象 比如這個對象數(shù)量多的有點反常，本來期待會被GC回收但是卻沒有
•  根據(jù)類型查找存活對象一覽
• 探索從某個對象找出GC ROOT一覽

轉(zhuǎn)自https://www.cnblogs.com/yudongdong/p/9701727.html