JVM初窥：垃圾收集器（一）

参考书籍：《深入理解Java虚拟机——JVM高级特性与最佳实践(第2版)》

Java语言出来之前，程序开发更多的是使用C或者C++语言，然而在C或者C++语言中存在一个很大的矛盾：创建对象时要不断地调用对象的构造方法来为对象开辟空间，对象用完之后又需要不断地去调用析构方法来释放它所占的内存空间，既要写构造方法，又要写析构方法，很多时候都是在做重复的工作。为了解决这一矛盾，垃圾收集器（Garbage Collection，GC）应运而生。

说起垃圾收集器（Garbage Collection，GC），大部分人都把这项技术当作Java语言的伴生产物。事实上，GC的历史比Java久远，1960年诞生于MIT的Lisp是第一门真正使用内存动态分配和垃圾收集技术的语言。
当Lisp还在胚胎时期时，人们就在思考GC需要完成的3件事情：

• 哪些内存需要回收？
• 什么时候回收？
• 如何回收？

由于Java运行时数据区域中的程序计数器、虚拟机栈、本地方法栈3个区域随线程而生，随线程而灭；栈中的栈帧随着方法的进入和退出而有条不紊地执行着入栈和出栈操作。每一个栈帧中分配多少内存基本上是在类结构确定下来时就已知的，因此这几个区域的内存分配和回收都具备确定性，在这几个区域就不需要过多考虑回收的问题，因为方法结束或者线程结束时，内存自然就跟随着回收了。

垃圾收集器回收的重点区域是：Java堆和方法区。

“存活”or“死去”

垃圾收集器在对对象进行回收之前，需先判断对象是“存活”着，还是已经“死去”（即不可能再被任何途径使用的对象）。垃圾收集器只会对那些已经“死去”的对象进行回收。
常用的判断对象是否存活的算法有以下两种：
1、  引用计数算法
引用计数（Reference Counting）算法是垃圾收集器中的早期策略。在这种算法中，堆中每个对象（不是引用）都有一个引用计数。对于一个对象 A，只要有任何一个对象引用了 A，则A 的引用计数器就加 1，当引用失效时，引用计数器就减 1。任何时刻引用计数为0的对象就是不可能再被使用的，即已经“死去”。
引用计数算法实现简单，判定效率也很高。但是这个算法有明显的缺陷，对于循环引用的情况下，循环引用的对象就不会被回收。如A=B,B=A, 此时，对象 A 和对象B 的引用计数器都不为 0。但是在系统中却不存在任何第 3 个对象引用了 A 或 B。也就是说，A 和 B 是应该被回收的垃圾对象，但由于垃圾对象间相互引用，从而使垃圾收集器无法识别，引起内存泄漏。
2、  根搜索算法
这种算法的基本思路是通过一系列名为“GC Roots”的对象作为起始点，从这些节点开始向下搜索，搜索所走过的路径称为引用链（Reference Chain），当一个对象到GC Roots没有任何引用链相连（用图论的话来说，就是从GC Roots到这个对象不可达）时，就证明此对象是不可用的。如下图所示（蓝色表示依然存活的对象，橙色表示可回收的对象），对象ObjD、ObjE虽然彼此有关联，但是它们到GC Roots是不可达的，所以它们将会被判定为是可回收的对象。

在Java语言里，可作为GC Roots的对象包括下面几种：

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

再谈引用

无论是通过引用计数算法判断对象的引用数量，还是通过根搜索算法判断对象的引用链是否可达，判断对象是否存活都与“引用有关”，所以我们在此再谈谈引用。

在JDK 1.2之后，Java对引用的概念进行了扩充，将引用分为强引用（ Strong Reference）、软引用（ Soft Reference）、弱引用（ Weak Reference）、虚引用（ Phantom Reference）四种，这四种引用强度依次逐渐减弱。
1、强引用就是指在程序代码之中普遍存在的，类似“Object obj = new Object()”这类的引用，只要强引用还存在，垃圾收集器永远不会回收掉被引用的对象。当内存空间不足，Java虚拟机宁愿抛出OutOfMemoryError错误，使程序异常终止，也不会靠随意回收具有强引用的对象来解决内存不足的问题。如果不使用时，可以赋值obj=null，显示的设置obj为null，则GC认为该对象不存在引用，这时候就可以回收此对象。

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

软引用可以和一个引用队列（ReferenceQueue）联合使用，如果软引用所引用的对象被垃圾回收器回收，Java虚拟机就会把这个软引用加入到与之关联的引用队列中。

软引用主要应用于内存敏感的高速缓存，在Android系统中经常使用到。一般情况下，Android应用会用到大量的默认图片，这些图片很多地方会用到。如果每次都去读取图片，由于读取文件需要硬件操作，速度较慢，会导致性能较低。所以我们考虑将图片缓存起来，需要的时候直接从内存中读取。但是，由于图片占用内存空间比较大，缓存很多图片需要很多的内存，就可能比较容易发生OutOfMemory异常。这时，我们可以考虑使用软引用技术来避免这个问题发生。SoftReference可以解决oom的问题，每一个对象通过软引用进行实例化，这个对象就以cache的形式保存起来，当再次调用这个对象时，那么直接通过软引用中的get()方法，就可以得到对象中的资源数据，这样就没必要再次进行读取了，直接从cache中就可以读取得到，当内存将要发生OOM的时候，GC也能回收该内存，防止oom发生。
3、弱引用也是用来描述非必需对象的，但是它的强度比软引用更弱一些，被弱引用关联的对象只能生存到下一次垃圾收集发生之前。，当JVM进行垃圾回收时，无论当前内存是否充足，都会回收掉只被弱引用关联的对象。在JDK 1.2之后，用WeakReference类来实现弱引用。弱引用与软引用的区别在于：只具有弱引用的对象拥有更短暂的生命周期。
以下代码用于对比在内存充足的情况下，调用System.gc()之后，软引用与弱引用关联对象的不同回收结果。

import java.lang.ref.WeakReference;/** * VM Args:-XX:+PrintHeapAtGC */public class ReferenceTest {public static void main(String[] args) {byte[] bytes = new byte[1024 * 1024 * 5];/** * 取消softBytes所在行注释，在内存充足的情况下，GC不会回收所关联的byte数组。 */// SoftReference<byte[]> softBytes=new SoftReference<byte[]>(bytes);/** * 取消weakBytes所在行注释，在内存充足的情况下，GC也会成功回收所关联的byte数组。 */// WeakReference<byte[]> weakBytes=new WeakReference<byte[]>(bytes);bytes = null;System.gc();}}

执行程序，根据PrintHeapAtGC所打印出来的堆内存回收日志，可得出以下结论：软引用关联的对象未被回收，而弱引用关联的对象被成功回收了。

4、虚引用也称为幽灵引用或者幻影引用，它是最弱的一种引用关系。和前面的软引用、弱引用不同，它并不影响对象的生命周期。在JDK 1.2之后，用PhantomReference类来实现虚引用。如果一个对象与虚引用关联，则跟没有引用与之关联一样，在任何时候都可能被垃圾回收器回收。为一个对象设置虚引用关联的唯一目的就是能在这个对象被收集器回收时收到一个系统通知。

死里逃生----finalize()方法

被判定为已经“死亡”的对象并不是一定会被JVM回收。一个对象在被回收之前，至少要经历两次标记过程：初次被判定为已经“死亡”后，对象将会被第一次标记并且进行一次筛选,筛选的条件是此对象是否有必要执行finalize()方法。当对象没有覆盖finalize()方法,或者finalize()方法已经被虚拟机调用过，虚拟机将这两种情况都视为“没有必要执行”(即意味着直接回收)。
如果这个对象被判定为有必要执行finalize()方法,那么这个对象将会放置在一个叫做F-Queue的队列之中,并在稍后由一个由虚拟机自动建立的、低优先级的Finalizer线程去执行它。这里所谓的“执行”是指虚拟机会触发这个方法,但并不承诺会等待它运行结束,这样做的原因是,如果一个对象在finalize()方法中执行缓慢,或者发生了死循环(更极端的情况),将很可能会导致F-Queue队列中其他对象永久处于等待,甚至导致整个内存回收系统崩溃。

finalize()方法是对象逃脱死亡命运的最后一次机会,稍后GC将对F-Queue中的对象进行第二次小规模的标记,如果对象要在finalize()中成功拯救自己——只要重新与引用链上的任何一个对象建立关联即可,譬如把自己(this关键字)赋值给某个类变量或者对象的成员变量,那在第二次标记时它将被移除出“即将回收”的集合;如果对象这时候还没有逃脱,那基本上它就真的被回收了。

public class FinalizeEscapeGC {public static FinalizeEscapeGC SAVE_HOOK = null;public void isAlive() {System.out.println("yes,i am still alive:)");}@Overrideprotected void finalize() throws Throwable {super.finalize();System.out.println("finalize mehtod executed!");FinalizeEscapeGC.SAVE_HOOK = this;}public static void main(String[] args) throws Throwable {SAVE_HOOK = new FinalizeEscapeGC();// 对象第一次成功拯救自己SAVE_HOOK = null;System.gc();// 因为finalize方法优先级很低,所以暂停0.5秒以等待它Thread.sleep(500);if (SAVE_HOOK != null) {SAVE_HOOK.isAlive();} else {System.out.println("no,i am dead:(");}// 下面这段代码与上面的完全相同,但是这次自救却失败了SAVE_HOOK = null;System.gc();// 因为finalize方法优先级很低,所以暂停0.5秒以等待它Thread.sleep(500);if (SAVE_HOOK != null) {SAVE_HOOK.isAlive();} else {System.out.println("no,i am dead:(");}}}

运行结果：

finalize mehtod executed!yes,i am still alive:)no,i am dead:(

从运行结果来看SAVE_HOOK对象的finalize()方法确实被GC收集器触发过，，并且在被收集前成功逃脱了。

另一个值得注意的地方是，代码中有两段完全一样的代码片段，执行结果却是一次逃脱成功，一次失败，这是因为任何一个对象的finalize()方法都只会被系统自动调用一次，如果对面面临下一次回收，它的finalize()方法不会被再次执行，因此第二段代码的自救行动失败了。

回收方法区

很多人以为方法区（或者HotSopt VM中的永久代）是没有垃圾收集的，Java虚拟机规范中确实说过可以不要求虚拟机在方法区实现垃圾收集，而且性价比一般较低，在对的新生代生一般能回收70%~95%的空间，而永久代远低于此。
永久代的垃圾收集主要回收两部分内容：废弃常量和无用的类。 回收废弃常量与回收Java堆中的对象非常相似。以常量池中字面量的回收为例，若字符串“abc”已经进入常量池中，但当前系统没有任何String对象引用常量池中的“abc”常量，也没有其他地方引用该字面量，若发生内存回收，且必要的话，该“abc”就会被系统清理出常量池。常量池中其他的类（接口）、方法、字段的符号引用与此类似。

无用的类需要满足3个条件：

• 该类所有的实例都已经被回收，即Java堆中不存在该类的任何实例； 
• 加载该类的ClassLoader已经被回收； 
• 该类对应的java.lang.Class对象没有在任何地方被引用，无法在任何地方通过反射访问该类的方法。

虚拟机可以对满足上述3个条件的无用类进行回收，此处仅仅是“可以”，而并不是和对象一样，不使用了就必然回收。