垃圾回收之判定对象存活

前言

说起垃圾回收集，很多人以为这是java语言的伴生物。事实上，垃圾收集的历史远远比java久远。Lisp是第一门使用内存动态分配和垃圾收集技术的语言。之前我们介绍过了java虚拟级运行时的各个区域，其中程序计数器，虚拟机栈，本地方法栈，随线程而生，随线程而灭。而java堆和方法区有着显著的不确定性，所以本文后续讨论的内存分配和回收也是这一部分的内存。
既然是垃圾回收，那就得判断那些是垃圾（就是死去的对象），那些不是。

引用计数算法

在对象中添加一个引用计数器，每当一个对象引用它时，计数器值就加一，当引用失效时，计数器值减一，任何时刻计数器为零的对象都是不可能再被使用的。
客观的说引用计数器算法虽然占用了一些额外的内存空间来进行计数，但是它原理简单，判定效率很高。但是它有一些缺陷，比如两个对象相互引用的时候，这两个对象就不会被判定为死亡。

可达性分析算法

这个算法的基本思路就是通过一系列的GCroot的根对象作为起始节点集，从这些节点开始，根据引用关系向下搜索，搜索过程所走过的路径成为引用链，如果某个对象到GcROOT间没有任何引用链相连，则证明这个对象时不可能再被使用的。
java体系中，固定可作为Gc Root的对象包括以下几种
1.在虚拟机栈中引用的对象（例如各个线程被调用的方法堆栈中使用到的参数，局部变量，临时变量等等）
2.方法区中静态的属性引用的对象
3.方法区中常量引用的对象
4.本地方法jni应用的对象
5.java虚拟级内部的引用（例如class对象，系统类加载器）
6.所有被同步锁持有的对象
7.反应java虚拟级内部情况的jmxbean，本地代码缓存等
8.一些临时加入的其他对象

引用

说起引用首先的说下引用的定义，jdk1.2之前java中引用的定义，就是reference类型数据中存储的数值代表的事另一块内存的起始地址，就称改reference数据是代表某块内存的，某个对象的引用。jdk1.2之后，对引用的概念进行了扩充，将引用分为四种，强引用，软引用，弱引用，和虚引用。
1.强引用：就是传统引用的定义
2.软引用：就是用来描述一些还有用，但非必须的对象。在系统即将发生内存溢出前，会把这些对象列进回收范围内，进行第二次回收。
3.弱引用：也是用来描述非必须的对象，强度比软引用更弱一些。关联的对象只能生存对下一次垃圾收集发生为止（也就是第一次就给回收了，你现在存活下来说明你已经经过一次垃圾回收了，下次也就是第一次，从现在开始的第一次）
4.虚引用：也称为幽灵引用和幻影引用，它是最弱的一种引用关系。一个对象是否有虚引用的存在完全不会对其生存时间产生影响。虚引用的唯一目的就是能在这个对象被回收时，获得一个通知。

finalize()方法

真正宣告一个对象死亡，需要经历两次的标记过程。如果经历了可达性分析之后，发现没有与DCroot相连接的引用链，那么它就会标记第一次。随后进行一次晒选，筛选的条件是此对象是否有必要执行finalize（）方法。假如对象没有覆盖finalize（）方法，或者finalize（）方法已经被虚拟机调用过了，那么虚拟机将会视为没有必要执行。
如果这个对象被判定为，需要执行finalize（）方法，那么该对象将会被放在一个名为F-Quene的队列之中，并在稍后由虚拟机自动建立的优先度低的finalizer线程去执行他们的finalize（）方法。（这里的执行，是指一定会触发，并不保证到结束（原因是如果对象的finalize方法执行很慢，或者陷入死循环之后，会导致队列的其他对象处于用久等待，甚至会导致整个回收子系统的崩溃））。finalize（）方法是对象逃脱命运的的最后一次机会，稍后收集器会在队列中进行二次标记，如果对象在fianlize（）方法中成功的拯救自己（也就是和所谓的跟对象或者引用链建立起链接），就会把这个对象移出即将回收集合。（这里呢不推荐大家使用这个方法，推荐大家使用try-finally）

回收方法区

《java虚拟机规范》中提到过可以不要求虚拟机在方法区实现垃圾回收，事实上也确实未有实现或未能完整实现方法区类型卸载的收集器存在。
方法区的垃圾回收主要分为两部分： 废弃的常量和不在使用类型。判断一个常量是否废弃还是相对简单的。而判定一个类型是否属于不再使用的类，就比较麻烦了。需要同时满足下面三个条件：
1.该类所有实例都已被回收
2.加载该类的类加载器已经被回收
3.该类对应的java.lang.Class对象没有再任何地方被引用。
满足以上条件，就允许回收该类。当然也就是仅仅允许。
当然也不是说任何条件下都不对这个方法区进行回收。（例如在大量使用反射，动态代理等等这种场景，还是需要java虚拟机具备类卸载能力的，以保证不会对方法区造成过大的内存压力）