垃圾回收机制GC知识再总结兼谈如何用好GC

一、为什么需要GC

应用程序对资源操作，通常简单分为以下几个步骤：

1、为对应的资源分配内存

2、初始化内存

3、使用资源

4、清理资源

5、释放内存

应用程序对资源（内存使用）管理的方式，常见的一般有如下几种：

1、手动管理：C,C++

2、计数管理：COM

3、自动管理：.NET,Java,PHP,GO…

但是，手动管理和计数管理的复杂性很容易产生以下典型问题：

1.程序员忘记去释放内存

2.应用程序访问已经释放的内存

产生的后果很严重，常见的如内存泄露、数据内容乱码，而且大部分时候，程序的行为会变得怪异而不可预测，还有Access Violation等。

.NET、Java等给出的解决方案，就是通过自动垃圾回收机制GC进行内存管理。这样，问题1自然得到解决，问题2也没有存在的基础。

总结：无法自动化的内存管理方式极容易产生bug，影响系统稳定性，尤其是线上多服务器的集群环境，程序出现执行时bug必须定位到某台服务器然后dump内存再分析bug所在，极其打击开发人员编程积极性，而且源源不断的类似bug让人厌恶。

二、GC是如何工作的

GC的工作流程主要分为如下几个步骤：

1、标记(Mark)

2、计划(Plan)

3、清理(Sweep)

4、引用更新(Relocate)

5、压缩(Compact)

public class MyClass
{
private bool isDisposed = false;

~MyClass()
{
Console.WriteLine("Enter destructor...");

lock (this) //some situation lead to deadlock
{
if (!isDisposed)
{
Console.WriteLine("Do Stuff...");
}
}
}
}

MyClass
通过如下代码进行调用：

var instance = new MyClass();

Monitor.Enter(instance);
instance = null;

GC.Collect();
GC.WaitForPendingFinalizers();

Console.WriteLine("instance is gabage collected");

上述代码将会导致死锁。原因分析如下：

1、客户端主线程调用代码Monitor.Enter(instance)代码段lock住了instance实例

2、接着手动执行GC回收，主（Finalizer)线程会执行MyClass析构函数

3、在MyClass析构函数内部，使用了lock (this)代码，而主（Finalizer)线程还没有释放instance（也即这里的this），此时主线程只能等待

虽然严格来说，上述代码并不是GC的错，和多线程操作似乎也无关，而是Lock使用不正确造成的。

同时请注意，GC的某些行为在Debug和Release模式下完全不同（Jeffrey Richter在<<CLR Via C#>>举过一个Timer的例子说明这个问题）。比如上述代码，在Debug模式下你可能发现它是正常运行的，而Release模式下则会死锁。

七、当GC遇到多线程

这一段主要参考<<CLR Via C#>>的线程劫持一节。

前面讨论的垃圾回收算法有一个很大的前提就是：只在一个线程运行。而在现实开发中，经常会出现多个线程同时访问托管堆的情况，或至少会有多个线程同时操作堆中的对象。一个线程引发垃圾回收时，其它线程绝对不能访问任何线程，因为垃圾回收器可能移动这些对象，更改它们的内存位置。CLR想要进行垃圾回收时，会立即挂起执行托管代码中的所有线程，正在执行非托管代码的线程不会挂起。然后，CLR检查每个线程的指令指针，判断线程指向到哪里。接着，指令指针与JIT生成的表进行比较，判断线程正在执行什么代码。

如果线程的指令指针恰好在一个表中标记好的偏移位置，就说明该线程抵达了一个安全点。线程可在安全点安全地挂起，直至垃圾回收结束。如果线程指令指针不在表中标记的偏移位置，则表明该线程不在安全点，CLR也就不会开始垃圾回收。在这种情况下，CLR就会劫持该线程。也就是说，CLR会修改该线程栈，使该线程指向一个CLR内部的一个特殊函数。然后，线程恢复执行。当前的方法执行完后，他就会执行这个特殊函数，这个特殊函数会将该线程安全地挂起。然而，线程有时长时间执行当前所在方法。所以，当线程恢复执行后，大约有250毫秒的时间尝试劫持线程。过了这个时间，CLR会再次挂起线程，并检查该线程的指令指针。如果线程已抵达一个安全点，垃圾回收就可以开始了。但是，如果线程还没有抵达一个安全点，CLR就检查是否调用了另一个方法。如果是，CLR再一次修改线程栈，以便从最近执行的一个方法返回之后劫持线程。然后，CLR恢复线程，进行下一次劫持尝试。所有线程都抵达安全点或被劫持之后，垃圾回收才能使用。垃圾回收完之后，所有线程都会恢复，应用程序继续运行，被劫持的线程返回最初调用它们的方法。

实际应用中，CLR大多数时候都是通过劫持线程来挂起线程，而不是根据JIT生成的表来判断线程是否到达了一个安全点。之所以如此，原因是JIT生成表需要大量内存，会增大工作集，进而严重影响性能。

概念叙述到此结束，手都抄软了^_^，这书卖的贵和书里面的理论水平一样有道理。

这里再说一个真实案例。某web应用程序中大量使用Task，后在生产环境发生莫名其妙的现象，程序时灵时不灵，根据数据库日志（其实还可以根据Windows事件跟踪（ETW）、IIS日志以及dump文件），发现了Task执行过程中有不规律的未处理的异常，分析后怀疑是CLR垃圾回收导致，当然这种情况也只有在高并发条件下才会暴露出来。

八、开发中的一些建议和意见

由于GC的代价很大，平时开发中注意一些良好的编程习惯有可能对GC有积极正面的影响，否则有可能产生不良效果。

1、尽量不要new很大的object，大对象（>=85000Byte）直接归为G2代，GC回收算法从来不对大对象堆（LOH）进行内存压缩整理，因为在堆中下移85000字节或更大的内存块会浪费太多CPU时间

2、不要频繁的new生命周期很短object，这样频繁垃圾回收频繁压缩有可能会导致很多内存碎片，可以使用设计良好稳定运行的对象池（ObjectPool）技术来规避这种问题

3、使用更好的编程技巧，比如更好的算法、更优的数据结构、更佳的解决策略等等

update:.NET4.5.1及其以上版本已经支持压缩大对象堆，可通过System.Runtime.GCSettings.LargeObjectHeapCompactionMode进行控制实现需要压缩LOH。可参考这里。

根据经验，有时候编程思想里的空间换时间真不能乱用，用的不好，不但系统性能不能保证，说不定就会导致内存溢出（Out Of Memory），关于OOM，可以参考我之前写过的一篇文章有效预防.NET应用程序OOM的经验备忘。

之前在维护一个系统的时候，发现有很多大数据量的处理逻辑，但竟然都没有批量和分页处理，随着数据量的不断膨胀，隐藏的问题会不断暴露。然后我在重写的时候，都按照批量多次的思路设计实现，有了多线程、多进程和分布式集群技术，再大的数据量也能很好处理，而且性能不会下降，系统也会变得更加稳定可靠。

九、GC线程和Finalizer线程

GC在一个独立的线程中运行来删除不再被引用的内存。

Finalizer则由另一个独立（高优先级CLR)线程来执行Finalizer的对象的内存回收。

对象的Finalizer被执行的时间是在对象不再被引用后的某个不确定的时间，并非和C++中一样在对象超出生命周期时立即执行析构函数。

GC把每一个需要执行Finalizer的对象放到一个队列(从终结列表移至freachable队列）中去，然后启动另一个线程而不是在GC执行的线程来执行所有这些Finalizer，GC线程继续去删除其他待回收的对象。

在下一个GC周期，这些执行完Finalizer的对象的内存才会被回收。也就是说一个实现了Finalize方法的对象必需等两次GC才能被完全释放。这也表明有Finalize的方法（Object默认的不算）的对象会在GC中自动“延长”生存周期。

特别注意：负责调用Finalize的线程并不保证各个对象的Finalize的调用顺序，这可能会带来微妙的依赖性问题(见<<CLR Via C#>>一个有趣的依赖性问题）。

最后感慨一下，反复看一本好书远远比看十本二十本不那么靠谱的书收获更多。

参考：

<<CLR Via C#>>

<<深入理解Java虚拟机>>

<<C# In Depth>>

<<Think In Java>>

https://msdn.microsoft.com/en-us/library/ms979205.aspx

http://msdn.microsoft.com/zh-cn/magazine/cc188793%28en-us%29.aspx