jvm垃圾收集之对象的死活

1.对象存活判定

1.1引用计数算法

1.1.1 算法描述

给对象添加一个引用计数器，每当有一个地方引用该对象时，计数值就加1；当引用失效时，计数值就减1；任何时刻计数器为0的对象就是不可能再被使用的。

1.1.2 优点

实现简单，判定效率高。微软的COM(Component Object Model)计数、使用ActionScript3的FlashPlayer、Python语音和游戏领域的Squirrel中使用计数算法进行内存管理。

1.1.3 缺点

它难以解决对象之间相互循环引用的问题。

例子：

public class ReferenceCountingGC {
	public Object instance = null;
	public static final int _1MB = 1024 * 1024;
	/**
	 * 这个成员属性的唯一意义就是占点内存，以便能在GC日志汇总看清楚是否被回收过
	 */
	private byte[] bigSize = new byte[2*_1MB];
	public static void main(String[] args) {
		//设置rcg1指向的对象和rcg2指向的对象引用计数值分别为count1=0，count2=0
		ReferenceCountingGC rcg1 = new ReferenceCountingGC();//count1=count1+1=1
		ReferenceCountingGC rcg2 = new ReferenceCountingGC();//count2=count2+1=1
		rcg1.instance = rcg2;//count2=count2+1=2
		rcg2.instance = rcg1;//count1=count1+1=2
		rcg1 = null;//rcg1引用失效，count1=count1-1=1
		rcg2 = null;//rcg2引用失效，count2=count2-1=1
		//此时count1=1,count2=1
		//若jvm采用引用计数算法，则此时rcg1和rcg2指向的对象都不会被回收
		//但其实这两个对象已经不可能被访问
//		假设这时发生GC，rcg1和rcg2是否会被回收？
		System.gc();
	}
}

运行结果如下：

[GC (System.gc()) [PSYoungGen: 6093K->648K(38400K)] 6093K->656K(125952K), 0.0009357 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]

[Full GC (System.gc()) [PSYoungGen: 648K->0K(38400K)] [ParOldGen: 8K->530K(87552K)] 656K->530K(125952K), [Metaspace: 2632K->2632K(1056768K)], 0.0053747 secs] [Times: user=0.02 sys=0.00, real=0.00 secs]

Heap

 PSYoungGen      total 38400K, used 333K [0x00000000d5c00000, 0x00000000d8680000, 0x0000000100000000)

  eden space 33280K, 1% used [0x00000000d5c00000,0x00000000d5c534a8,0x00000000d7c80000)

  from space 5120K, 0% used [0x00000000d7c80000,0x00000000d7c80000,0x00000000d8180000)

  to   space 5120K, 0% used [0x00000000d8180000,0x00000000d8180000,0x00000000d8680000)

 ParOldGen       total 87552K, used 530K [0x0000000081400000, 0x0000000086980000, 0x00000000d5c00000)

  object space 87552K, 0% used [0x0000000081400000,0x0000000081484860,0x0000000086980000)

 Metaspace       used 2638K, capacity 4486K, committed 4864K, reserved 1056768K

  class space    used 285K, capacity 386K, committed 512K, reserved 1048576K

从运行结果中可以看出，虚拟机并没有因为这两个对象相互引用就不回收它们，这便说明了JVM并不是通过引用计数算法来判断对象是否存活的。

1.2 可达性分析算法

1.2.1 算法描述

通过一系列的称为“GC Roots”的对象作为起始点，从这些节点开始向下搜索，搜索所走过的路径称为引用链（Reference Chain），当一个对象到GC Roots没有任何引用链相连时，则证明此对象不可用的，即会被判断为是可回收的对象。

1.2.2 使用该算法的语言

Java，C#，以及Lisp语言都是使用可达性分析算法来判断对象是否存活的。

1.2.3 可作为GC Roots的对象类型

• 虚拟机栈（栈帧中的局部变量表）中引用的对象
• 方法区中类静态属性引用的对象
• 方法区中常量引用的对象
• 本地方法栈中JNI（也就是Native方法）引用的对象

2.java中的引用

2.1 引用的定义

JDK1.2以前的定义:如果reference类型的数据中存储的数值代表的是另外一块内存的起始地址，就称这块内存代表着一块引用。

JDk1.2之后，将引用分为了强引用、软引用、弱引用、虚引用，这四种引用强度依次减弱。

2.2 四种引用的概述

• 强引用：即形如“Object obj = new Object()”这类的引用，只要强引用存在，垃圾回收器永远不会回收掉被引用的对象。
• 软引用：用来描述一些还有用但非必需的对象。对于软引用关联着的对象，在系统将要发生内存溢出异常之前，将会把这些对象裂锦回收范围之内进行第二个回收。如果这次回收还没有足够的内存，才会抛出内存溢出异常。在JDK1.2之后，提供了SoftReference类来实现软引用。
• 弱引用：描述非必需对象，强度比软引用弱，被弱引用关联的对象只能生存到下一次垃圾收集发生之前。在JDK1.2之后，提供了WeakReference类来实现弱引用。
• 虚引用：也称为幽灵引用，最弱的引用关系。为一个对象设置虚引用关联的唯一目的就是能在这个对象呗收集器回收时收到一个系统通知。在jdk1.2之后，提供了PhantomReference类来实现虚引用。

3.对象的死活

3.1 误区

在可达性分析算法中不可达的对象，不一定会死亡。

3.2 对象死亡的标记过程

如果对象在可达性分析中发现没有与GC Roots相连接的引用链，那么会进行第一次标记，同时会进行一次筛选，当对象没有覆盖finalize()方法或者finalize()已经被jvm调用过时，虚拟机将不会回收该对象。如果该对象被判断为有必要执行finalize()方法，那么这个对象会被放置在一个叫F-Queue的队列中，并在稍后执行它，但是不保证它运行结束。finalize()方法是对象免除死亡的最后一次机会，稍后GC将会对F-Queue中的对象进行第二次标记，如果对象在finalize()方法中与其他对象建立了关联，那么它将会被移除出“即将回收”的集合，自救成功。反之自救失败，该对象将真正地被回收

对象标记过程简要流程图

一个对象的finalize方法只会被执行一次，如果对象在执行过一次finalize()方法后成功自救，那么它就失去了第二次自救的机会，当它再次判定为不可达对象的的时候，它将必死无疑，无法自救。

PS：本文所有要点均为笔者阅读《深入理解Java虚拟机》一书后的简单提炼和总结，若有纰漏，望指正。