C#知识点扫盲——GC（Garbage Collector）

摘自：关于C#中垃圾回收GC杂谈

在.Net里面垃圾收集的工作方式：

运行.NET应用程序时，程序创建出来的对象实例都会被CLR跟踪，CLR都是有记录哪些对象还会被用到（存在引用关系）；哪些对象不会再被用到（不存在引用关系）。CLR会整理不会再被用到的对象，在恰当的时机，按一定的规则销毁部分对象，释放出这些对象所占用的内存。

CLR是怎么记录对象引用关系的？

CLR会把对象关系做成一个“树图”，这样标记他们的引用关系

CLR是怎么释放对象的内存的？

关键的技术是：CLR把没用的对象转移到一起去，使内存连续，新分配的对象就在这块连续的内存上创建，这样做是为了减少内存碎片。注意！CLR不会移动大对象

垃圾收集器按什么规则收集垃圾对象？

CLR按对象在内存中的存活的时间长短，来收集对象。时间最短的被分配到第0代，最长的被分配到第2代，一共就3代。

一般第0贷的对象都是较小的对象，第2代的对象都是较大的对象，第0代对象GC收集时间最短（毫秒级别），第2代的对象GC收集时间最长。当程序需要内存时（或者程序空闲的时），GC会先收集第0代的对象，

收集完之后发现释放的内存仍然不够用，GC就会去收集第1代，第2代对象。（一般情况是按这个顺序收集的）

如果GC跑过了，内存空间依然不够用，那么就抛出了OutOfMemoryException异常。

GC跑过几次之后，第0代的对象仍然存在，那么CLR会把这些对象移动到第1代，第1代的对象也是这样。

既然有了垃圾收集器，为什么还要Dispose方法和析构函数？

因为CLR的缘故，GC只能释放托管资源，不能释放非托管资源（数据库链接、文件流等）。

那么该如何释放非托管资源呢？

一般我们会选择为类实现IDispose接口，写一个Dispose方法。

让调用者手动调用这个类的Dispose方法（或者用using语句块来自动调用Dispose方法）

Dispose执行时，析构函数和垃圾收集器都还没有开始处理这个对象的释放工作

有时候，我们不想为一个类型实现Dispose方法，我们想让他自动的释放非托管资源。那么就要用到析构函数了。

析构函数是个很奇怪的函数，调用者无法调用对象的析构函数，析构函数是由GC调用的。

你无法预测析构函数何时会被调用，所以尽量不要在这里操作可能被回收的托管资源，析构函数只用来释放非托管资源

GC释放包含析构函数的对象，比较麻烦（需要干两次才能干掉她），

CLR会先让析构函数执行，再收集它占用的内存。

我们需要手动执行垃圾收集吗？什么场景下这么做？

GC什么时候执行垃圾收集是一个非常复杂的算法（策略）

大概可以描述成这样：

如果GC发现上一次收集了很多对象，释放了很大的内存，

那么它就会尽快执行第二次回收，

如果它频繁的回收，但释放的内存不多，

那么它就会减慢回收的频率。

所以，尽量不要调用GC.Collect()这样会破坏GC现有的执行策略。

除非你对你的应用程序内存使用情况非常了解，你知道何时会产生大量的垃圾，那么你可以手动干预垃圾收集器的工作

我有一个大对象，我担心GC要过很久才会收集他，

关于弱引用和垃圾收集之间的关系？

当一个大对象被使用后不存在引用关系时，GC就会自动回收它占用的内存。

当这个对象足够大的情况下，GC在回收它时，可能时间稍微会长点，当用户需要再次使用该对象时，我们可以从回收池中再次提取该对象，这里就涉及到弱引用，代码如下：

var bss = new BsCtl(BrowserContainer);  
var vbss = new WeakReference<BsCtl>(bss);  
bss = null;  
BsCtl ok;              
vbss.TryGetTarget(out ok);  
//如果没有进行垃圾收集OK不会为NULL  
if (ok == null)  
{  
    //如果已经进行了垃圾收集，就会执行这段代码  
    ok = new BsCtl(BrowserContainer);  
}  

• 1
• 2
• 3
• 4
• 5
• 6
• 7
• 8
• 9
• 10
• 11

垃圾收集随时可以收集bss对象，

如果收集了，就会进入if语句块，如果没有收集，就不会进入if语句块，TryGetTarget(out ok)就成功把bss从垃圾堆里捞回来了。

注意：这里只说了短弱引用，没有提及长弱引用，我觉得长弱引用使用的场景较少。

【算法工作原理】

垃圾收集器的本质,就是跟踪所有被引用到的对象，整理不再被引用的对象，回收相应的内存。

这听起来类似于一种叫做“引用计数(Reference Counting)”的算法，然而这种算法需要遍历所有对象，并维护它们的引

用情况，所以效率较低些，并且在出现“环引用”时很容易造成内存泄露。所以.Net中采用了一种叫做“标记与清除

(Mark Sweep)”算法来完成上述任务。

“标记与清除”算法，顾名思义，这种算法有两个本领：

“标记”本领——垃圾的识别：从应用程序的root出发，利用相互引用关系，遍历其在Heap上动态分配的所有对

象，没有被引用的对象不被标记，即成为垃圾；存活的对象被标记，即维护成了一张“根-对象可达图”。其实，

CLR会把对象关系看做“树图”，无疑，了解数据结构的都知道，有了“树图”的概念，会加快遍历对象的速度。

检测并标记对象引用，是一件很有意思的事情，有很多方法可以做到，但是只有一种是效率最优的，.Net中是利

用栈来完成的，在不断的入栈与出栈中完成检测：先在树图中选择一个需要检测的对象，将该对象的所有引用压栈，

如此反复直到栈变空为止。栈变空意味着已经遍历了这个局部根(或者说是树图中的节点)能够到达的所有对象。树图

节点范围包括局部变量(实际上局部变量会很快被回收，因为它的作用域很明显、很好控制)、寄存器、静态变量，这

些元素都要重复这个操作。一旦完成，便逐个对象地检查内存，没有标记的对象变成了垃圾。

“清除”本领——回收内存：启用Compact算法，对内存中存活的对象进行移动，修改它们的指针，使之在内存

中连续，这样空闲的内存也就连续了，这就解决了内存碎片问题，当再次为新对象分配内存时，CLR不必在充满碎片

的内存中寻找适合新对象的内存空间，所以分配速度会大大提高。但是大对象（large object heap）除外，GC不会移

动一个内存中巨无霸，因为它知道现在的CPU不便宜。通常，大对象具有很长的生存期，当一个大对象在.NET托管

堆中产生时，它被分配在堆的一个特殊部分中，移动大对象所带来的开销超过了整理这部分堆所能提高的性能。

Compact算法除了会提高再次分配内存的速度，如果新分配的对象在堆中位置很紧凑的话，高速缓存的性能将会

得到提高，因为一起分配的对象经常被一起使用(程序的局部性原理)，所以为程序提供一段连续空白的内存空间是很

重要的。

垃圾收集器优点：

因为我没有很丰富的C/C++编程经验，如果想谈垃圾收集器的好处，那么势必要和C/C++这样的较低级的语言对比。所以一般性的回答都是减少内存使用不当的BUG，提升编程效率之类的问题。

为什么要使用GC呢？也可以说是为什么要使用内存自动管理？有下面的几个原因：

1、提高了软件开发的抽象度； 
2、程序员可以将精力集中在实际的问题上而不用分心来管理内存的问题； 
3、可以使模块的接口更加的清晰，减小模块间的偶合； 
4、大大减少了内存人为管理不当所带来的Bug； 
5、使内存管理更加高效。 
总的说来就是GC可以使程序员可以从复杂的内存问题中摆脱出来，从而提高了软件开发的速度、质量和安全性。