Java虚拟机(二)-垃圾收集器与内存分配策略

1.概述

垃圾收集器，大部分人都会觉得这项技术当做Java语言的伴生产物。但是事实上GC的历史比Java久远，1960年诞生于MIT的Lisp是第一门真正使用内存动态分配和垃圾收集技术的语言。

GC主要需要完成下面三件事情:

1.哪些内存需要回收？

2.什么时候回收？

3.如何回收？

当前似乎垃圾回收技术已经十分成熟了，那我们还需要学习吗？

答案是肯定的，当需要排除各种内存溢出，内存泄露问题时，当垃圾收集成为系统达到更大的并发量的瓶颈时。

2.各个常见的回收算法

2.1引用计数算法

这似乎是最常见的算法，它的原理是给对象中添加一个引用计数器，每当有一个地方用到它时，计数器值就+1；当引用失效时，计数器就-1，任何时刻计数器为0时的对象就是不可能再被使用的。

客观来讲，这个算法实现简单，判定效率也高，但是很遗憾的是主流Java虚拟中并没有选用引用计数算法来管理内存，主要原因是它无法解决对象间循环引用的问题。

package gcalgorithm;

public class QuoteNumberAlgorithm {
	
	public Object instance = null;
	
	private static final int _1MB = 1024 * 1024;
	
	private byte[] bigSize = new byte[2 * _1MB];
	
	public static void testGC() {
		QuoteNumberAlgorithm objA = new QuoteNumberAlgorithm();
		QuoteNumberAlgorithm objB = new QuoteNumberAlgorithm();
		
		objA.instance = objB;
		objB.instance = objA;
		
		objA = null;
		objB =null;
		
		System.gc();
	}

}

例如上面的例子，一旦使用了引用计数算法，将无法回收objA和objB因为他们相互引用着，引用计数器都为1.

2.2可达性分析算法

在主流的商用程序语言中(Java和C#)，都是使用可达性分析算法判断对象是否存活的。这个算法的基本思路就是通过一系列名为GC Roots的对象作为起始点，从这些节点开始向下搜索，搜索所走过的路径称为引用链(Reference Chain)，当一个对象到GC Roots没有任何引用链相连时，则证明此对象是不可用的，下图对象object5, object6, object7虽然有互相判断，但它们到GC Roots是不可达的，所以它们将会判定为是可回收对象。

那么那些点可以作为GC Roots呢？一般来说，如下情况的对象可以作为GC Roots：

1. 虚拟机栈(栈桢中的本地变量表)中的引用的对象
2. 方法区中的类静态属性引用的对象
3. 方法区中的常量引用的对象
4. 本地方法栈中JNI（Native方法）的引用的对象

3.再谈引用

无论使用什么算法判断对象是否存活，都与引用有关，在JDK1.2之后，Java对引用的概念进行了扩充，将引用分为强引用，软引用，弱引用，虚引用，这四种强度一次减弱。

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

2.软引用是用来描述一些还有用但非必需的对象。对于软引用关联着的对象，在系统将要发生内存溢出异常之前，将会把这些对象列进回收范围之中进行第二次回收，如果这次回收还没有足够的内存，才会抛出内存溢出异常。在JDK1.2之后，提供了SoftReference类来实现软引用。

3.弱引用也是用来描述一些还有用但非必需的对象，被弱引用关联的对象只能生存到下一次垃圾收集发生之前。当垃圾收集器工作时，无论当前内存是否足够，都会回收掉只被弱引用关联的对象。在JDK1.2之后，提供了WeakReference类来实现弱引用。

4.虚引用也称为幽灵引用或者幻影引用，他是最弱的引用关系，一个对象是否有虚引用的存在，完全不会对其生存时间构成影响，也无法通过虚引用来取得一个对象实例。为一个对象设置虚引用关联的唯一目的就是能在这个对象被收集器回收时收到一个系统通知。在JDK1.2之后，提供了PantomReference类来实现虚引用。

4.对象的拯救

就算使用了可达性分析算法中不可达的对象，也并非是“非死不可”，这时候他们处于缓刑阶段，要真正让对象死亡，至少要经过两次标志过程。步骤为：

1.当发现对象没有和GCRoots相连接，他会被第一次标记。

2.当对象没有覆盖finalize()方法或者这个方法已经被执行了，会进行第二次标志（如果对象覆盖了finalize（）方法且没有执行，那么这个对象将会放置在一个叫F-Queue的队列中，并在稍后由一个虚拟机自动建立的，低优先级的Finalizer线程执行它，这里的执行是指虚拟机会触发这个方法，但不承诺会等待它运行完成，这样做是因为如果finalize（）执行缓慢，或者发生了死循环等，将会导致队列中其他的对象永久处于等待状态，甚至内存崩溃。finalize（）方法是对象逃离死亡的最后一次机会）

package gcalgorithm;

public class FinalizeEscapeGC {

	public static FinalizeEscapeGC SAVE_HOOK = null;

	public void isAlive() {
		System.out.println("i am alive");
	}

	@Override
	protected void finalize() throws Throwable {
		// TODO Auto-generated method stub
		super.finalize();
		System.out.println("finalize() is running");
		FinalizeEscapeGC.SAVE_HOOK = this;
	}

	public static void main(String[] args) throws InterruptedException {

		SAVE_HOOK = new FinalizeEscapeGC();

		SAVE_HOOK = null;
		System.gc();

		Thread.sleep(500);

		if (SAVE_HOOK != null) {
			SAVE_HOOK.isAlive();
		} else {
			System.out.println("i am dead");
		}

		// 下面代码和上面代码完全一样

		SAVE_HOOK = null;
		System.gc();

		Thread.sleep(500);

		if (SAVE_HOOK != null) {
			SAVE_HOOK.isAlive();
		} else {
			System.out.println("i am dead");
		}
	}

}

运行结果

finalize() is running
i am alive
i am dead

从结果可以看出，SAVE_HOOK对象的finalize()方法确实被GC收集器触发过，并在回收前逃脱了。

另外为什么一次逃脱成功，另一次逃脱失败？这是因为任何一个对象的finalize()方法都只会被系统自动调用一次，如果有下一次，那这个方法将不会被调用，不鼓励大家使用这种方法进行拯救对象，它的运行代价高昂，不确定性大，甚至有可能没被执行。