Java虚拟机——对象是否死亡，以及两次标记过程图解

在Java堆中存放着几乎所有的对象实例，当垃圾回收器在对Java堆进行回收前，就需要对里面的对象进行是否存活的判断。然而，要真正宣告一个对象的死亡，是需要经历两次标记过程的。接下来就来具体分析。

1、两种判断对象是否存活的方法（但注意，这两种均不能真正宣告对象死亡。）——

1.1 引用计数器法

 ① 工作原理：给对象添加一个引用计数器，每当由一个地方引用它时，计数器值就加1；当引用失效时，计数器值就减1；任何时刻计数器为0的对象就是不可能再被使用的。

②优点：实现简单，判定效率也很高；

    缺点：他很难解决对象之间相互循环引用的问题。

例子：对象objA与objB都有字段instance，赋值令objA.instance=objB，及obj.instance=objA，除此之外，这两个对象再无任何引用。实际上这两个对象已经不可能再被访问了，但是由于它们相互引用对方——>导致它们的引用计数都不为零——>引用计数算法无法通知GC收集器回收它们。

③注意：上例经过测试后发现，GC日志中包含“4603K->210K”，意味着虚拟机仍然对它们进行了回收——>虚拟机并不是通过引用计数算法来判断对象是否存活的。

1.2 可达性分析算法

①基本思路：通过一系列的成为“GC Roots”的对象作为起始点，从这些节点开始向下搜索，搜索所走过的路径成为引用链，当一个对象到GC ROOTS没有任何引用链相连时，则证明此对象时不可用的。

②Java语言中GC Roots的对象包括下面几种：

   (1.虚拟机栈（栈帧中的本地变量表）中引用的对象

   (2.方法区中类静态属性引用的对象

   (3.方法区中常量引用的对象

              (4.本地方法栈JNI（Native方法）引用的对象

2.引用

分析上面所说的两种判定方法后，可以发现它们都与“引用”有关。

JDK1.2以前，引用的定义（纯粹，但太过狭隘）——如果reference（引用）类型的数据中存储的数值代表的是另一块内存的起始地址，就称这块内存代表着一个引用。

So——>我们所期望描述这样一类对象：当内存空间足够的时候，能够保留在内存中；但如果内存空间在进行垃圾收集之后还是很紧张，则可以抛弃这些对象。（例如很多系统中的缓存功能）

So——> JDK1.2之后，java对引用的概念进行了扩充，分为以下几种——（由强到弱）

2.1 强引用

就是在程序代码之中普遍存在的，类似Object obj = new Object() 这类的引用，只要强引用还存在，垃圾收集器永远不会回收掉被引用的对象。

2.2 软引用

用来描述一些还有用但并非必须的元素。对于它在系统将要发生内存溢出异常之前，将会把这些对象列进回收范围之中进行第二次回收，如果这次回收还没有足够的内存才会抛出内存溢出异常。（SoftReference类用来实现弱引用）

2.3 弱引用

用来描述非必须对象的，但是它的强度比软引用更弱一些，被引用关联的对象只能生存到下一次垃圾收集发生之前，当垃圾收集器工作时，无论当前内存是否足够都会回收掉只被弱引用关联的对象。（WeakReference类用来实现弱引用）

2.4 虚引用

也称为幽灵引用或者幻影引用，是最弱的一种引用关系。一个对象是否存在虚引用，完全不会对其生存时间造成影响，也无法通过虚引用来去的一个对象实例。 它的唯一目的就是：能在这个对象被收集器回收时收到一个系统通知。（PhantomReference类用来实现弱引用）

 

3、真正宣告一个对象生存还是死亡？

即使是在可达性分析算法中不可达的对象，也不并非“非死不可”，此时它们暂时处于“缓刑”阶段。

要真正宣告一个对象死亡，至少要经历两次标记过程，如下图所示：

 

注意：

1、重新与引用链上的任何一个对象建立关联，譬如可以把自己（this关键字）赋值给某个类变量或者对象的成员变量。

例如：FinalizeEscapeGC.SAVE_HOOK=this；

2、虚拟机触发finalize()方法的语句：System.gc()；

Finalize方法：任何一个对象的finalize()方法都只会被系统自动调用一次，如果对象面临下一次回收，它的finalize()方法不会被再次执行，因此，如果再次使用该方法，对象的自救行动是不会成功的了。

注意：不建议使用这种方法来拯救对象，因为它的运行代价高昂，不确定性大，同时也无法保证各个对象的调用顺序。可以使用try-finally或其他方式来代替，会获得更好的效果。

 

关于对象是生存还是死亡的判断，就是以上的内容了。已经完成了判断，接下来，就是如何对死亡的对象进行垃圾回收了。具体内容可见之后的博客。

参考文献：《深入理解Java虚拟机》