深入理解GC

什么是GC

GC如其名，就是垃圾收集，当然这里仅就内存而言。Garbage Collector（垃圾收集器，在不至于混淆的情况下也成为GC）以应用程序的root为基础，遍历应用程序在Heap（堆）上动态分配的所有对象，通过识别它们是否被引用来确定哪些对象是已经死亡的哪些仍需要被使用。已经不再被应用程序的root或者别的对象所引用的对象就是已经死亡的对象，即所谓的垃圾，需要被回收。这就是GC工作的原理。为了实现这个原理，GC有多种算法。比较常见的算法有Reference Counting，Mark Sweep，Copy Collection等等。
垃圾收集器的本质,就是跟踪所有被引用到的对象，整理不再被引用的对象，回收相应的内存。
.Net clr把所有的引用对象都分配到托管堆上。当一个进程初始化之后，运行时会保留一段连续的空白内存空间，这块内存空间就是托管堆。托管堆会记录一个指针，我们叫它NextObjPtr，这个指针指向下一个对象的分配地址，最初的时候，这个指针指向托管堆的起始位置。
应用程序使用new操作符创建一个新对象，这个操作符首先要确认托管堆剩余空间能放得下这个对象，如果能放得下，就把NextObjPtr指针指向这个对象，然后调用对象的构造函数，new操作符返回对象的地址。
当应用程序调用new操作符创建对象时，有可能已经没有内存来存放这个对象了。托管堆可以检测到NextObjPtr指向的空间是否超过了堆的大小，如果超过了就说明托管堆满了，就需要做一次垃圾回收了。
CLR初始化时会为0/1/2这三代选择一个预算的容量。0代通常以256 KB-4 MB之间的预算开始，1代的典型起始预算为512 KB-4 MB，2代不受限制，最大可扩展至操作系统进程的整个内存空间。

Mark-Compact标记压缩算法

当GC堆需要进行清理的时候，GC收集器就会通过一定的算法来清理堆中的对象，并且版本不同算法也不同。最主要的则为Mark-Compact标记-压缩算法。
这个算法的大概含义就是，通过一个图的数据结构来收集对象的根，这个根就是引用地址，可以理解为指向托管堆的这根关系线。当触发这个算法时，会检查图中的每个根是否可达，如果可达就对其标记，然后在堆上找到剩余没有标记(也就是不可达)的对象进行删除，这样，那些不在使用的堆中对象就删除了。

前面说了，因为nextObjPtr的缘故，在堆中分配的对象都是连续分配的，因为未被标记而被删除，那么经过删除后的堆就会显得支零破碎，那么为了避免空间碎片化，所以需要一个操作来让堆中的对象再变得紧凑、连续，而这样一个操作就叫做：Compact压缩。
而对堆中的分散的对象进行挪动后，还会修改这些被挪动对象的指向地址，从而得以正确的访问，最后重新更新一下nextObjPtr指针，周而复始。

而为了优化内存结构，减少在图中搜索的成本，GC机制又为每个托管堆对象定义了一个属性，将每个对象分成了3个等级，这个属性就叫做：代，0代、1代、2代。

每当new一个对象的时候，该对象都会被定义为第0代，当GC开始回收的时候，先从0代回收，在这一次回收动作之后，0代中没有被回收的对象则会被定义成第1代。当回收第1代的时候，第1代中没有被清理掉的对象就会被定义到第2代

GC中几个关键点

1）首先gc认为所有对象都是垃圾，然后从全局变量开始建立可达对象图，遍历完所有的对象，一个图形成了。
2）大对象在第二代的loh里面，gc不对它们做移动处理（memcpy函数）
3）当gc来临的时候先移动第零代对象，找一个连续地址，将零代理不连续内存的可达对象memcpy过去，然后修复一下程序集对这里面对象的引用指针指向这个新的内存里面来，并标记这里面的对象为第一代
4）当对象有finalize方法时，会有一个finalize queue放置这些对象的指针，当GC来临时没有finalize方法的垃圾对象被干掉，有finalize方法的垃圾对象不会被干掉(代龄升级)而是将finalize queue中的对象指针移到到一个f-reachable队列中，同时启用一个新线程去执行f-reachable队列中的对象的finalize方法，执行完毕将这个对象的指针从f-reachable队列中移除。下次GC来临就可以讲这些被执行过finalize方法的对象干掉了。

简单把.NET的GC算法看作Mark-Compact算法
阶段1: Mark-Sweep 标记清除阶段
先假设heap中所有对象都可以回收，然后找出不能回收的对象，给这些对象打上标记，最后heap中没有打标记的对象都是可以被回收的
阶段2: Compact 压缩阶段
对象回收之后heap内存空间变得不连续，在heap中移动这些对象，使他们重新从heap基地址开始连续排列，类似于磁盘空间的碎片整理

Heap内存经过回收、压缩之后，可以继续采用前面的heap内存分配方法，即仅用一个指针记录heap分配的起始地址就可以

主要处理步骤：将线程挂起=>确定roots=>创建reachable objects graph=>对象回收=>heap压缩=>指针修复

可以这样理解roots：heap中对象的引用关系错综复杂（交叉引用、循环引用），形成复杂的graph，roots是CLR在heap之外可以找到的各种入口点。GC搜索roots的地方包括全局对象、静态变量、局部对象、函数调用参数、当前CPU寄存器中的对象指针（还有finalization queue）等。主要可以归为2种类型：已经初始化了的静态变量、线程仍在使用的对象（stack+CPU register）

Reachable objects：指根据对象引用关系，从roots出发可以到达的对象。例如当前执行函数的局部变量对象A是一个root object，他的成员变量引用了对象B，则B是一个reachable object。从roots出发可以创建reachable objects graph，剩余对象即为unreachable，可以被回收

指针修复是因为compact过程移动了heap对象，对象地址发生变化，需要修复所有引用指针，包括stack、CPU register中的指针以及heap中其他对象的引用指针

Debug和release执行模式之间稍有区别，release模式下后续代码没有引用的对象是unreachable的，而debug模式下需要等到当前函数执行完毕，这些对象才会成为unreachable，目的是为了调试时跟踪局部对象的内容

传给了COM+的托管对象也会成为root，并且具有一个引用计数器以兼容COM+的内存管理机制，引用计数器为0时这些对象才可能成为被回收对象

Pinned objects指分配之后不能移动位置的对象，例如传递给非托管代码的对象（或者使用了fixed关键字），GC在指针修复时无法修改非托管代码中的引用指针，因此将这些对象移动将发生异常。pinned objects会导致heap出现碎片，但大部分情况来说传给非托管代码的对象应当在GC时能够被回收掉

GC相关的数据结构

与.net GC相关的数据结构有三个Managed Heap，Finalization Queue和Freachable Queue。

Managed Heap

Managed Heap是一个设计简单而优化的堆，它与传统的C-runtime的堆不太一样。它的简单管理方法是为了提高对堆的管理速度，同时也是基于一个简单的（也是不可能的）假设。对Managed Heap的管理假设内存是无穷无尽的。在Managed Heap上有一个称为NextObjPtr的指针，这个指针用于指示堆上最后一个对象的地址。当有一个新的对象要分配到这个堆上时，所要做的仅仅是将NextObjPtr的值加上新对象的大小形成新的NextObjPtr。这只是一个简单的相加，当NextObjPtr的值超出了Managed Heap边界的时候说明堆已经满了，GC将被启动。

Finalization Queue和Freachable Queue

这两个队列和.net对象所提供的Finalize方法有关。这两个队列并不用于存储真正的对象，而是存储一组指向对象的指针。当程序中使用了new操作符在Managed Heap上分配空间时，GC会对其进行分析，如果该对象含有Finalize方法则在Finalization Queue中添加一个指向该对象的指针。在GC被启动以后，经过Mark阶段分辨出哪些是垃圾。再在垃圾中搜索，如果发现垃圾中有被Finalization Queue中的指针所指向的对象，则将这个对象从垃圾中分离出来，并将指向它的指针移动到Freachable Queue中。这个过程被称为是对象的复生（Resurrection），本来死去的对象就这样被救活了。为什么要救活它呢？因为这个对象的Finalize方法还没有被执行，所以不能让它死去。Freachable Queue平时不做什么事，但是一旦里面被添加了指针之后，它就会去触发所指对象的Finalize方法执行，之后将这个指针从队列中剔除，这是对象就可以安静的死去了。.net framework的System.GC类提供了控制Finalize的两个方法，ReRegisterForFinalize和SuppressFinalize。前者是请求系统完成对象的Finalize方法，后者是请求系统不要完成对象的Finalize方法。ReRegisterForFinalize方法其实就是将指向对象的指针重新添加到Finalization Queue中。这就出现了一个很有趣的现象，因为在Finalization Queue中的对象可以复生，如果在对象的Finalize方法中调用ReRegisterForFinalize方法，这样就形成了一个在堆上永远不会死去的对象，像凤凰涅槃一样每次死的时候都可以复生。

GC分代的好处

采用Generation的最大好处就在于每次GC不用对整个Heap（堆）都进行处理，而是每次处理一小块。对于Generation 0中的对象，因为它们死亡的可能性最大，所以对它们GC的次数可以安排多一些，而其它相对死亡的可能性小一些的对象所在的Generation可以少安排几次GC。这样做就使得GC的速度得到了一定程度的提高：

GC对性能的影响

还有一点，垃圾回收是对性能有影响的。
GC虽然有很多优化策略，但总之，只要当它开始回收垃圾的时候，为了防止线程在CLR检查期间对对象更改状态，所以CLR会暂停进程中的几乎所有线程(所以线程太多也会影响GC时间)，而暂停的时间就是应用程序卡死的时间，为此，对于具体的处理细节，GC提供了2种配置模式让我们选择。

第一种为：单CPU的工作站模式，专为单CPU处理器定做。这种模式会采用一系列策略来尽可能减少GC回收中的暂停时间。
而工作站模式又分为并发(或后台)与不并发两种，并发模式表现为响应时间快速，不并发模式表现为高吞吐量。

第二种为：多CPU的服务器模式，它会为每个CPU都运行一个GC回收线程，通过并行算法来使线程能真正同时工作，从而获得性能的提升。

我们可以通过在Config文件中更改配置来修改GC模式，如果没有进行配置，那么应用程序总是默认为单CPU的工作站的并发模式，并且如果机器为单CPU的话，那么配置服务器模式则无效。

如果在工作站模式中想禁用并发模式，则应该在config中运行时节点添加
如果想更改至服务器模式，则可以添加 。

性能建议

虽然我们可以选择适合的GC工作模式来改善垃圾回收时的表现，但在实际开发中我们更应该注意减少不必要的内存开销。

几个建议是，减换需要创建大量的临时变量的模式、考虑对象池、大对象使用懒加载、对固定容量的集合指定长度、注意字符串操作、注意高频率的隐式装箱操作、延迟查询、对于不需要面向对象特性的类用static、需要高性能操作的算法改用外部组件实现(p/invoke、com)、减少throw次数、注意匿名函数捕获的外部对象将延长生命周期、可以阅读GC相关运行时配置在高并发场景注意变换GC模式…

什么时候触发GC

1、当GC的代的预算大小已经达到阈值而无法对新对象分配空间的时候，比如GC的第0代已满；

2、显式调用System.GC.Collect()(显示调用要慎重，因为手动调用可能会与自动执行的GC冲突，从而导致无法预知的问题)；

3、其他特殊情况，比如，操作系统内存不足、CLR卸载AppDomain、CLR关闭，甚至某些极端情况下系统参数设置改变也可能导致GC回收。