关于垃圾回收GC

     先看如下代码：

Objet obj = new Object();  

     变量obj是一个内存，new Object()是另一个内存，此时，变量obj所对应的内存中存储的数值就是对象占用的那块内存的首地址（即保存着对象的引用）。变量是放在栈里的，而对象是放在堆里的。所以上面的语句，obj变量放在栈里，保存着Object对象的引用（Object对象在堆中的首地址），而new Object()是在堆上申请了一块内存，这块内存放着Object这个对象。

 

      变量一般是有存活时间的。比如，一个方法内的变量只存活在这个方法内，也就是出了这个方法，这个变量就不存在了。那么，问题来了。当变量已经不存在时，它引用的对象实际上已经没有存在的意义，可是对象却还在堆上存在。C++在变量即将失效时要求程序员自己来释放存放在堆上的对象（在析构函数里利用delete ）。而JAVA却要求程序员不管在堆上的对象。也就是说，不需要程序员自己来释放堆上的对象。这些无用的对象就像垃圾一样，那么，就没有一个清洁工来打扫一下，来保持内存的干净么？答案是有，那就是垃圾回收器(GC)。

 

     当然，GC并不会一直运行，就像清洁工不会一天24小时打扫街道一样。它只会在堆即将放满时，才开始垃圾回收操作。当GC开始垃圾回收时，它要处理的第一个问题就是判断哪些是垃圾哪些不是垃圾。一般来说会有下面两种算法:

引用计数算法（Reference Counting）

　　最初的想法，也是很多教科书判断对象是否存活的算法是这样的：给对象中添加一个引用计数器，当有一个地方引用它，计数器加1，当引用失效，计数器减1，任何时刻计数器为0的对象就是不可能再被使用的。

　　客观的说，引用计数算法实现简单，判定效率很高，在大部分情况下它都是一个不错的算法，但引用计数算法无法解决对象循环引用的问题。举个简单的例子：对象A和B分别有字段b、a，令A.b=B和B.a=A，除此之外这2个对象再无任何引用，那实际上这2个对象已经不可能再被访问，但是引用计数算法却无法回收他们。

根搜索算法（GC Roots Tracing）

　　在实际生产的语言中（Java、C#、甚至包括前面提到的Lisp），都是使用根搜索算法判定对象是否存活。算法基本思路就是通过一系列的称为“GC Roots”的点作为起始进行向下搜索，当一个对象到GC Roots没有任何引用链（Reference Chain）相连，则证明此对象是不可用的。在Java语言中，GC Roots包括：

　　1.在VM栈（帧中的本地变量）中的引用
　　2.方法区中的静态引用
　　3.JNI（即一般说的Native方法）中的引用

生存还是死亡？

　　判定一个对象死亡，至少经历两次标记过程：如果对象在进行根搜索后，发现没有与GC Roots相连接的引用链，那它将会被第一次标记，并在稍后执行他的finalize()方法（如果它有的话）。这里所谓的“执行”是指虚拟机会触发这个方法，但并不承诺会等待它运行结束。这点是必须的，否则一个对象在finalize()方法执行缓慢，甚至有死循环什么的将会很容易导致整个系统崩溃。finalize()方法是对象最后一次逃脱死亡命运的机会，稍后GC将进行第二次规模稍小的标记，如果在finalize()中对象成功拯救自己（只要重新建立到GC Roots的连接即可，譬如把自己赋值到某个引用上），那在第二次标记时它将被移除出“即将回收”的集合，如果对象这时候还没有逃脱，那基本上它就真的离死不远了。

　　需要特别说明的是，这里对finalize()方法的描述可能带点悲情的艺术加工，并不代表笔者鼓励大家去使用这个方法来拯救对象。相反，笔者建议大家尽量避免使用它，这个不是C/C++里面的析构函数，它运行代价高昂，不确定性大，无法保证各个对象的调用顺序。需要关闭外部资源之类的事情，基本上它能做的使用try-finally可以做的更好。
     

        在确定了哪些对象是垃圾后，GC就可以开始垃圾回收了。

 

        1.“标记－清除算法”（Mark-Sweep）

        我们在标记号哪些是垃圾后，就可以开始回收所有需要回收的对象。这就是标记--清除算法，它的主要缺点有两个，一是效率问题，标记和清理两个过程效率都不高，二是空间问题，标记清理之后会产生大量不连续的内存碎片，空间碎片太多可能会导致后续使用中无法找到足够的连续内存而提前触发另一次的垃圾搜集动作。

       2.“复制”（Copying）搜集算法

       为了解决效率问题，一种称为“复制”（Copying）的搜集算法出现，它将可用内存划分为两块，每次只使用其中的一块，当半区内存用完了，仅将还存活的对象复制到另外一块上面，然后就把原来整块内存空间一次过清理掉。这样使得每次内存回收都是对整个半区的回收，内存分配时也就不用考虑内存碎片等复杂情况，只要移动堆顶指针，按顺序分配内存就可以了，实现简单，运行高效。只是这种算法的代价是将内存缩小为原来的一半，未免太高了一点。

       3.“标记－整理”（Mark-Compact）算法

        复制收集算法在对象存活率高的时候，效率有所下降。更关键的是，如果不想浪费50%的空间，就需要有额外的空间进行分配担保用于应付半区内存中所有对象都100%存活的极端情况，所以在老年代一般不能直接选用这种算法。因此人们提出另外一种“标记－整理”（Mark-Compact）算法，标记过程仍然一样，但后续步骤不是进行直接清理，而是令所有存活的对象一端移动，然后直接清理掉这端边界以外的内存。

      

       4.“分代收集”（Generational Collecting）算法

       当前商业虚拟机的垃圾收集都是采用“分代收集”（Generational Collecting）算法，这种算法并没有什么新的思想出现，只是根据对象不同的存活周期将内存划分为几块。一般是把Java堆分作新生代和老年代，这样就可以根据各个年代的特点采用最适当的收集算法，譬如新生代每次GC都有大批对象死去，只有少量存活，那就选用复制算法只需要付出少量存活对象的复制成本就可以完成收集。