一：背景 前幾篇我們聊的都是 非托管記憶體泄漏，這一篇我們再看下如何用 PerfView 來排查 托管記憶體泄漏 ，其實 托管記憶體泄漏 比較好排查，尤其是用 WinDbg，畢竟C#是帶有豐富的元數據，不像C++下去就是二進位。 二：如何分析 PerfView 用的是權重占比來尋找可疑的問題函數，為了方便 ...
一：背景
前幾篇我們聊的都是 非托管記憶體泄漏，這一篇我們再看下如何用 PerfView 來排查 托管記憶體泄漏 ，其實 托管記憶體泄漏 比較好排查，尤其是用 WinDbg，畢竟C#是帶有豐富的元數據，不像C++下去就是二進位。
二：如何分析
PerfView 用的是權重占比來尋找可疑的問題函數，為了方便講述，我們先上一段問題代碼。
internal class Program
{
static void Main(string[] args)
{
Task.Run(Alloc1);
Task.Run(Alloc2);
Task.Run(Alloc3);
Console.ReadLine();
}
static void Alloc1()
{
var list = new List<string>();
for (int i = 0; i < 200000; i++)
{
list.Add(string.Join(",", Enumerable.Range(0, 1000)));
}
Console.WriteLine("Alloc1 處理完畢");
}
static void Alloc2()
{
var list = new List<string>();
for (int i = 0; i < 100; i++)
{
list.Add(string.Join(",", Enumerable.Range(0, 1000)));
}
Console.WriteLine("Alloc2 處理完畢");
}
static void Alloc3()
{
var list = new List<string>();
for (int i = 0; i < 100; i++)
{
list.Add(string.Join(",", Enumerable.Range(0, 1000)));
}
Console.WriteLine("Alloc3 處理完畢");
}
}
這段代碼運行完成後會發現記憶體占用高達 1.5G，如下圖所示：
在真實場景中，你根本不知道是誰占用了這麼大的記憶體，在分析武器庫中，用 WinDbg 肯定是最穩的，既然是介紹 PerfView 工具，得用它來分析。
二：PerfView 分析
1. 到底是哪裡的泄漏
分析之前，還是要先搞清楚到底是哪裡的泄漏，才好用 PerfView 追查下來，首先用 !eeheap -gc 查看下托管堆的占用大小。
0:005> !eeheap -gc
Number of GC Heaps: 1
generation 0 starts at 0x0000000072D7AEC0
generation 1 starts at 0x0000000072B1B790
generation 2 starts at 0x0000000002841000
ephemeral segment allocation context: none
segment begin allocated committed allocated size committed size
0000000002840000 0000000002841000 000000001283FB10 0000000012840000 0xfffeb10(268430096) 0xffff000(268431360)
0000000023E80000 0000000023E81000 0000000033E7F0A8 0000000033E80000 0xfffe0a8(268427432) 0xffff000(268431360)
00000000347D0000 00000000347D1000 00000000447CFA98 00000000447D0000 0xfffea98(268429976) 0xffff000(268431360)
0000000045A60000 0000000045A61000 0000000055A5E2A0 0000000055A60000 0xfffd2a0(268423840) 0xffff000(268431360)
0000000055A60000 0000000055A61000 0000000065A5F7B8 0000000065A60000 0xfffe7b8(268429240) 0xffff000(268431360)
0000000065A60000 0000000065A61000 0000000073252ED8 00000000735F6000 0xd7f1ed8(226434776) 0xdb95000(230248448)
Large object heap starts at 0x0000000012841000
segment begin allocated committed allocated size committed size
0000000012840000 0000000012841000 0000000012C21130 0000000012C22000 0x3e0130(4063536) 0x3e1000(4067328)
Pinned object heap starts at 0x000000001A841000
000000001A840000 000000001A841000 000000001A845C38 000000001A852000 0x4c38(19512) 0x11000(69632)
Total Allocated Size: Size: 0x5dbcdce8 (1572658408) bytes.
Total Committed Size: Size: 0x5df71000 (1576472576) bytes.
------------------------------
GC Allocated Heap Size: Size: 0x5dbcdce8 (1572658408) bytes.
GC Committed Heap Size: Size: 0x5df71000 (1576472576) bytes.
從輸出中可以看到，當前的 托管堆 占用 1.5G, 這就說明當前的泄漏確實是 托管堆 的泄漏，這就給繼續分析指明瞭方向。
2. 使用 .NET Alloc 攔截
在 PerfView 中有一個 .NET Alloc 選項，它可以攔截每一次對象分配，然後記錄下 線程調用棧，再根據分配量計算權重,知道原理後，接下來就可以開啟 .NET Alloc 攔截。
需要註意的是，對於這個選項，需要先開啟收集，再啟動程式，等程式執行完畢後，點擊 Stop Collection ，稍等片刻，會看到如下截圖。
點擊 GC Heap Net MEM （Coarse Sampling） Stack 列表，選擇我們的進程，會看到當前的 System.String 權重占比最高，所以調查它的分配源就是當務之急了，截圖如下：
接下來雙擊 System.String 行，查看它的 Callers，逐一往下翻，終於找到了 Program.Alloc1() 方法，截圖如下：
到這裡就找到了問題函數 Alloc1() ，接下來就是探究源碼了哈。
3. 生產中可以用 .NET Alloc 嗎
現在大家都知道 .NET Alloc 可以實現對象分配攔截，但是在生產場景中，每秒的分配量可能達到幾十萬，上百萬，每一次分配都要攔截，會產生諸多的負面影響。
1） 程式速度變慢。
2） 產生非常大的 zip 文件。
如果你不在意的話，可以這麼使用，如果在意，建議用 .NET SampAlloc 選項，它是一種採樣的方式，每秒中的同類型分配最多只會採樣 100 次，所以在 性能 和 zip文件 兩個維度可以達到最優狀態。
接下來勾選 .NET SampAlloc 項，其他操作步驟一致，截圖如下：
有點意思的是，觀察到的占比都是 43.7% ，
