一：背景

1. 講故事

我們有一家top級的淘品牌店鋪，為了后續的加速計算，在程式啟動的時候灌入她家的核心資料到記憶體中，灌入完成后記憶體高達100G，雖然云上的機器記憶體有256G，然被這么劃掉一半看著還是有一點心疼的，可憐那些被擠壓的小啰啰程式??????，本以為是那些List，HashSet，Dictionary需要動態擴容虛占了很多記憶體，也就沒當一回事，后來過了一天發現記憶體回到了大概70多G，臥槽，不是所謂的集合虛占，而是GC沒給我回收呀，，，

2. windbg驗證一下

為了驗證我的說法，我就不去生產抓這個龐然大物的dump了，去測驗環境給大家抓一個，晚上清蒸，

!eeheap -gc 查看gc資訊


0:000> !eeheap -gc
Number of GC Heaps: 1
generation 0 starts at 0x0000019b0fc66b48
generation 1 starts at 0x0000019b0f73b138
generation 2 starts at 0x0000019a5da81000
ephemeral segment allocation context: none
         segment             begin         allocated              size
0000019a5da80000  0000019a5da81000  0000019a6da7ffb8  0xfffefb8(268431288)
0000019a00000000  0000019a00001000  0000019a0ffffe90  0xfffee90(268430992)
0000019a10000000  0000019a10001000  0000019a1ffffeb0  0xfffeeb0(268431024)
0000019a20000000  0000019a20001000  0000019a2fffffb0  0xfffefb0(268431280)
0000019a30000000  0000019a30001000  0000019a3ffffc50  0xfffec50(268430416)
0000019a40000000  0000019a40001000  0000019a4fffffc8  0xfffefc8(268431304)
0000019a7aad0000  0000019a7aad1000  0000019a8aacfd60  0xfffed60(268430688)
0000019a8cbf0000  0000019a8cbf1000  0000019a9cbefe10  0xfffee10(268430864)
0000019a9cbf0000  0000019a9cbf1000  0000019aacbefcb8  0xfffecb8(268430520)
0000019aacbf0000  0000019aacbf1000  0000019abcbefd18  0xfffed18(268430616)
0000019abcbf0000  0000019abcbf1000  0000019accbefd68  0xfffed68(268430696)
0000019accbf0000  0000019accbf1000  0000019adcbefcf8  0xfffecf8(268430584)
0000019adcbf0000  0000019adcbf1000  0000019aecbefdc0  0xfffedc0(268430784)
0000019af0e20000  0000019af0e21000  0000019b00e1ff28  0xfffef28(268431144)
0000019b00e20000  0000019b00e21000  0000019b10047178  0xf226178(253911416)
Large object heap starts at 0x0000019a6da81000
         segment             begin         allocated              size
0000019a6da80000  0000019a6da81000  0000019a756d0480  0x7c4f480(130348160)
0000019b10e20000  0000019b10e21000  0000019b133ca330  0x25a9330(39490352)
Total Size:              Size: 0xf940ee70 (4181782128) bytes.
------------------------------
GC Heap Size:            Size: 0xf940ee70 (4181782128) bytes.

從最后一行可以看到堆大小： GC Heap Size: Size: 0xf940ee70 (4181782128) bytes. 然后將4181782128 byte 轉化為GB： 4181782128/1024/1024/1024= 3.89G，

再來看一下3代中有多少free空閑塊，占了多少空間，為了方便查看，大家可以用一下sosex擴展，提供了很多方便的方法，

!dumpgen xxxx 依次把0，1，2 三個代中的free空間統計出來，


0:000> !dumpgen 0 -free -stat
       Count      Total Size      Type
-------------------------------------------------
         168      1,120,008   **** FREE ****

168 objects, 1,120,008 bytes

0:000> !dumpgen 1 -free -stat
       Count      Total Size      Type
-------------------------------------------------
         368          8,096   **** FREE ****

368 objects, 8,096 bytes

0:000> !dumpgen 2 -free -stat
       Count      Total Size      Type
-------------------------------------------------
  11,857,034  1,052,310,524   **** FREE ****

11,857,034 objects, 1,052,310,524 bytes

從上面輸出可以看到，三個代free objects的資訊：

空閑塊個數:168 + 368 + 11857034 = 11857570個，

空閑塊空間：1120008 + 8096 + 1052310524 = 1053438628 byte => 0.98G，

驚訝吧~， 3.89G的堆，等待被釋放的空間就有0.98G,占比高達25%，再看看第2代中有高達1185萬個空閑塊，說明堆碎片有多么嚴重，，，

所以等GC自己啟動回收壓縮釋放不知道猴年馬月，為了高效利用記憶體，不得已自己先給程式點個火，手工呼叫一下GC.Collect，讓程式記憶體降到了 3.89 - 0.98 = 2.91 G，

二：對GC代機制的理解

有不少程式員對gc中的代管理機制不是特別清楚，或者看過書之后理解也停留在理論上，沒法去驗證書中所說，其實我也不是特別理解，??????，作為一個準備好好玩自媒體人，不能讓您白來一趟哈，

1. CLR堆模型

當CLR不小心錯入程式世界的時候，會給你分配兩個堆，一個叫做小物件堆，一個叫做大物件堆，默認是以83k作為大小堆的分界線，當然你也可以自定義配置，堆上的空間由很多的記憶體段拼成的,可能你有點蒙，我畫張圖吧，

2. 對臨時記憶體段的解釋

看完上圖，可能大家有兩個疑問：

<1> 為啥小物件堆中有一個臨時記憶體段？

這是因為CLR做了很多假設，它假設在gen0和gen1上回收的物件會特別多，所以沒事就上去轉轉，CLR為了方便GC快速清理回收壓縮，，，就將gen0和gen1都放置在這個臨時記憶體段上，

你可能要問，有證據嗎？？？我就拿剛才的4G程式說話吧，


0:000> !eeheap -gc
Number of GC Heaps: 1
generation 0 starts at 0x0000019b0fc66b48
generation 1 starts at 0x0000019b0f73b138
generation 2 starts at 0x0000019a5da81000
ephemeral segment allocation context: none
         segment             begin         allocated              size
0000019a5da80000  0000019a5da81000  0000019a6da7ffb8  0xfffefb8(268431288)
0000019a00000000  0000019a00001000  0000019a0ffffe90  0xfffee90(268430992)
0000019a10000000  0000019a10001000  0000019a1ffffeb0  0xfffeeb0(268431024)
0000019a20000000  0000019a20001000  0000019a2fffffb0  0xfffefb0(268431280)
0000019a30000000  0000019a30001000  0000019a3ffffc50  0xfffec50(268430416)
0000019a40000000  0000019a40001000  0000019a4fffffc8  0xfffefc8(268431304)
0000019a7aad0000  0000019a7aad1000  0000019a8aacfd60  0xfffed60(268430688)
0000019a8cbf0000  0000019a8cbf1000  0000019a9cbefe10  0xfffee10(268430864)
0000019a9cbf0000  0000019a9cbf1000  0000019aacbefcb8  0xfffecb8(268430520)
0000019aacbf0000  0000019aacbf1000  0000019abcbefd18  0xfffed18(268430616)
0000019abcbf0000  0000019abcbf1000  0000019accbefd68  0xfffed68(268430696)
0000019accbf0000  0000019accbf1000  0000019adcbefcf8  0xfffecf8(268430584)
0000019adcbf0000  0000019adcbf1000  0000019aecbefdc0  0xfffedc0(268430784)
0000019af0e20000  0000019af0e21000  0000019b00e1ff28  0xfffef28(268431144)
0000019b00e20000  0000019b00e21000  0000019b10047178  0xf226178(253911416)
Large object heap starts at 0x0000019a6da81000
         segment             begin         allocated              size
0000019a6da80000  0000019a6da81000  0000019a756d0480  0x7c4f480(130348160)
0000019b10e20000  0000019b10e21000  0000019b133ca330  0x25a9330(39490352)
Total Size:              Size: 0xf940ee70 (4181782128) bytes.
------------------------------
GC Heap Size:            Size: 0xf940ee70 (4181782128) bytes.

從上面gc資訊中可以看到小物件堆中目前有 15個記憶體段，大物件堆有2個記憶體段, gen0的起始地址為0x0000019b0fc66b48,gen1的起始地址為0x0000019b0f73b138, 都落在了第15個記憶體段內 0000019b00e20000 0000019b00e21000 0000019b10047178 0xf226178(253911416)，其余記憶體段都被 gen2 占領，如果大家有點亂，先多看幾遍，等一下看我的演示，

<2> 臨時記憶體段大小是多少？

這個段的大小，需要看是x64還是x86機器，還要看GC是作業站模式還是服務器模式，不過msdn幫我們總結了，https://docs.microsoft.com/zh-cn/dotnet/standard/garbage-collection/fundamentals ，截個圖給大家看一下，

我的本機是x64版本,作業站模式，可以通過 !eeversion 查看一下，


0:000> !eeversion
4.8.3801.0 free
Workstation mode
SOS Version: 4.8.3801.0 retail build

對應圖中，我的臨時記憶體段的最大記憶體是256M，再回過頭用4G程式的來驗證一下記憶體段大小，用 allocated - begin 即可，


ephemeral segment allocation context: none
         segment             begin         allocated              size
0000019b00e20000  0000019b00e21000  0000019b10047178  0xf226178(253911416)

0:000> ? 0000019b10047178 - 0000019b00e21000
Evaluate expression: 253911416 = 00000000`0f226178

兩者差值為 253911416 byte => 242M ，可以看出離256M不遠了，等到了256M又要觸發GC啦，，，，

3. 代機制簡介

有了上面的基礎，我覺得你對GC的gen機制應該明白了，由于3個gen運行時預定空間是隨GC觸發隨時變動，所以就不知道某個時刻各個gen當時的空間觸發閾值，

接下來說一下三代的原理：當gen0滿了會觸發GC回收，將gen0中活物件送到gen1中，死的就消滅掉，當某時候gen1滿了，gen1的活物件會被送到gen2中，當下個某一次gen2滿了，就向作業系統申請新的記憶體段，所以你看到了4G程式占用了多達14個記憶體段，就是這么一個道理，沒什么復雜的，

三：代機制原理的代碼演示

我剛才也說了，很多人知道這個理論，不知道怎么去驗證，這里我就演示一下，先上代碼：


        public static void Main(string[] args)
        {
            Student student1 = new Student() { UserName = "cnblogs", Email = "[email protected]" };
            Student student2 = new Student() { UserName = "csdn", Email = "[email protected]" };

            Console.WriteLine("兩個物件已創建！雙雙進入 Gen0");
            Console.Read();

            student1 = null;
            GC.Collect();

            Console.WriteLine("Student1 已從Gen0中抹掉，助力Student2上Gen1，是否繼續？");
            Console.ReadKey();

            GC.Collect();
            Console.WriteLine("再次助力Student2上Gen2");
            Console.ReadKey();

            Console.WriteLine("全部執行結束！");
            Console.ReadLine();
        }
    }

    public class Student
    {
        public string UserName { get; set; }
        public string Email { get; set; }
    }

代碼很簡單，就是想讓你看一下student1和student2如何在gen0，gen1，gen2中游蕩，并且給你精準找出來，

1. 探究 gen0 上的student1 和 studnet2

先啟動程式，抓一下dump檔案，

0:000> !clrstack -l

ConsoleApp4.Program.Main(System.String[]) [C:\dream\Csharp\ConsoleApp1\ConsoleApp4\Program.cs @ 18]
    LOCALS:
        0x000000017d7feeb8 = 0x000001d0962c2f28
        0x000000017d7feeb0 = 0x000001d0962c2f48

0:000> !eeheap -gc
Number of GC Heaps: 1
generation 0 starts at 0x000001d0962c1030
generation 1 starts at 0x000001d0962c1018
generation 2 starts at 0x000001d0962c1000
ephemeral segment allocation context: none
         segment             begin         allocated              size
000001d0962c0000  000001d0962c1000  000001d0962c7fe8  0x6fe8(28648)
Large object heap starts at 0x000001d0a62c1000
         segment             begin         allocated              size
000001d0a62c0000  000001d0a62c1000  000001d0a62c9a68  0x8a68(35432)
Total Size:              Size: 0xfa50 (64080) bytes.
------------------------------
GC Heap Size:            Size: 0xfa50 (64080) bytes.

仔細看上面的輸出，從主執行緒的堆疊上可以看到student1和studnet2的地址依次為0x000001d0962c2f28, 0x000001d0962c2f48，而gen0的起始地址為：0x000001d0962c1030，剛好落在 gen0 的區間內，可能你有點蒙，我畫一張圖，

2. 探究 student1 被消滅，student2進入gen1

按下Enter鍵，執行后續代碼將student1=null，再執行GC操作，看下堆中又是如何？


0:000> !clrstack -l
ConsoleApp4.Program.Main(System.String[]) [C:\dream\Csharp\ConsoleApp1\ConsoleApp4\Program.cs @ 24]
    LOCALS:
        0x000000607e9fea50 = 0x0000000000000000
        0x000000607e9fea48 = 0x0000017f0dff2f38

000000607e9fec88 00007ff8e9396c93 [GCFrame: 000000607e9fec88] 
0:000> !eeheap -gc
Number of GC Heaps: 1
generation 0 starts at 0x0000017f0dff6ea0
generation 1 starts at 0x0000017f0dff1018
generation 2 starts at 0x0000017f0dff1000
ephemeral segment allocation context: none
         segment             begin         allocated              size
0000017f0dff0000  0000017f0dff1000  0000017f0dff8eb8  0x7eb8(32440)
Large object heap starts at 0x0000017f1dff1000
         segment             begin         allocated              size
0000017f1dff0000  0000017f1dff1000  0000017f1dff9a68  0x8a68(35432)
Total Size:              Size: 0x10920 (67872) bytes.
------------------------------
GC Heap Size:            Size: 0x10920 (67872) bytes.

如果弄明白了上一個案例，看這里就很簡單了，很清楚的看到studnet2落在了gen1區間段，不過從起始地址上看，gen1的空間變大了，，，我繼續畫一張圖，

3. 探究student2 送上了 gen2


0:000> !clrstack -l
ConsoleApp4.Program.Main(System.String[]) [C:\dream\Csharp\ConsoleApp1\ConsoleApp4\Program.cs @ 28]
    LOCALS:
        0x000000d340bfebb0 = 0x0000000000000000
        0x000000d340bfeba8 = 0x00000217b5df2f38

000000d340bfede8 00007ff8e9396c93 [GCFrame: 000000d340bfede8] 
0:000> !eeheap -gc
Number of GC Heaps: 1
generation 0 starts at 0x00000217b5df6f40
generation 1 starts at 0x00000217b5df6ea0
generation 2 starts at 0x00000217b5df1000
ephemeral segment allocation context: none
         segment             begin         allocated              size
00000217b5df0000  00000217b5df1000  00000217b5df8f58  0x7f58(32600)
Large object heap starts at 0x00000217c5df1000
         segment             begin         allocated              size
00000217c5df0000  00000217c5df1000  00000217c5df9a68  0x8a68(35432)
Total Size:              Size: 0x109c0 (68032) bytes.
------------------------------
GC Heap Size:            Size: 0x109c0 (68032) bytes.

很簡單，我就不畫圖了哈，student2的記憶體地址可是落在 gen2上哦~??????

四：總結

GC.Collect盡量少用，省的把內部的分配和回收演算法搞亂了，非要用的話也要理解之后再根據自己的場景使用哈，

本篇就說到這里，希望對你有幫助

如您有更多問題與我互動，掃描下方進來吧~

轉載請註明出處，本文鏈接：https://www.uj5u.com/net/42825.html

標籤：C#

上一篇：System.Linq.Dynamic字串轉委托

下一篇：C# 9.0 新特性預覽 - 型別推導的 new

記憶體遲遲下不去，可能你就差一個GC.Collect