一：背景
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的信息：
对象有:168 + 368 + 11857034 = 11857570个，
空间：1120008 + 8096 + 1052310524 = 1053438628 byte => 0.98G。
惊讶吧~， 3.89G的堆，等待被释放的空间有0.98G,占比高达25%，再看看第2代中有高达1185万的对象需要清理，说明在整个加载过程中，GC至少被触发2次。。。
所以等GC自己启动回收不知道猴年马月，为了高效利用内存，不得已自己先给程序点个火，让程序内存降到了 3.89 - 0.98 = 2.91 G。
二：对GC代机制的理解
有不少程序员对gc中的代管理机制不是特别清楚，或者看过书之后理解也停留在理论上，没法去验证书中所说，其实我也不是特别理解，作为一个准备好好玩自媒体人，不能让您白来一趟哈。 **
- 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 = "cnblogs@qq.com" };
Student student2 = new Student() { UserName = "csdn", Email = "csdn@qq.com" };
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尽量少用，省的把内部的分配和回收算法搞乱了，非要用的话也要理解之后再根据自己的场景使用哈。
本篇就说到这里，希望对你有帮助
