【JVM 垃圾收集器】— 对象已死吗
注：本文是垃圾收集器读书笔记，内容基本来自《深入理解Java虚拟机（第2版）》
要了解垃圾收集器（Garbage Collector，GC），需要从以下 3 个问题着手：
- 哪些内存需要回收？
- 什么时候回收？
- 如何回收？
本文解决的是第一个问题：垃圾收集器在对堆进行回收前，如何确定哪些对象还“存活”着，哪些已经“死去”。
引用计数算法
引用计数算法是这样的：给对象中添加一个引用计数器，每当有一个地方引用它，计数器就加 1,；当引用失效时，计数器值就减 1；任何时刻计数器值为 0 的对象就是不可能再被使用的。客观来说，引用计数算法的实现简单，判定效率高效，在大部分下是一个不错的算法。但是当前主流的 Java 虚拟机并没有采用引用计数算法来管理内存，其中最主要的原因是它很难解决对象之间循环引用的问题。
ReferenceCountingGC a = new ReferenceCountingGC();
ReferenceCountingGC b = new ReferenceCountingGC();
a.instance = b;
b.instance = a;
可达性分析算法
当前主流的 Java 虚拟机实现中，采用的是可达性分析（Reachability Analysis）来判定对象是否存活的。这个算法的基本思路如下
通过一系列的被称为“GC Roots”的对象作为起点，从这些节点开始向下搜索，搜索走过的路径称为引用链。当一个对象到 GC Roots 没有任何引用链相连时，则证明这个对象是不可达的。
就比如下图，Object 5、Object 6、Object 7 虽然互相关联，但是他们到 GC Roots 是不可达的，所以它们将会被判定为是可回收对象。
那何为 GC Roots？在 Java 语言中，可作为 GC Roots 的对象包括以下几种：
- 虚拟机栈（栈帧中的本地变量表）中引用的对象。
- 方法区中类静态属性引用的对象。
- 方法区中常量引用的对象。
- 本地方法栈中 JNI（Java Native Interface）引用的对象
引用
在 JDK 1.2 以前，Java 中的引用定义很传统：如果 reference 类型的数据中存储的数值代表另一块内存的起始地址，就称这块内存代表着一个引用。这种定义太过狭隘，一个对象在这种定义下只有被引用和没有被引用两种状态，对于如何描述一些“食之无味，弃之可惜”的对象就显得无能为力。我们希望能描述这样一类对象：
当内存空间还足够时，则能够留在内存之中；如果内存空间中在进行垃圾收集后还是非常紧张，则可以抛弃这些对象。
所以在 JDK 1.2 之后，Java 对引用的概念进行了扩充，将引用分为强引用（Strong Reference）、软引用（Soft Reference）、弱引用（Weak Reference）、虚引用（Phantom Reference） 4 种，这 4 种引用强度依次组件减弱。
强引用
强引用是代码中普遍存在的，类似“Object obj = new Object()”这类的引用，只要强引用还在，垃圾收集器永远不会回收掉被引用的对象。
软引用
软引用是用来描述一些还有用但并非必须的对象。对于软引用关联着的对象，在系统将要发生 OOM 之前，将会把这些对象列进回收范围之中进行第二次回收。如果这次回收还没有足够的内存，才会 OOM。JDK 1.2 之后，提供了 SoftReference 类来实现软引用。
弱引用
弱引用也是用来描述非必须对象的，但它的强度比软引用更弱一些，被弱引用关联的对象只能生存到下一次垃圾收集发生之前。当垃圾收集工作时，无论当时前内存是否足够，都会回收掉只被弱引用关联的对象。JDK 1.2 之后，提供了 WeakReference 类来实现弱引用。
虚引用
虚引用也称为幽灵引用或幻影引用，它是最弱的一种引用关系。一个对象是否有虚引用的存在，完全不会对其生存时间构成影响，也无法通过虚引用来取得一个对象实例。为一个对象设置虚引用关联的唯一目的就是能在这个对象被收集器回收时收到一个系统通知。JDK 1.2 之后，提供了 PhantomReference 类来实现虚引用。
两次标记
一个对象即使在可达性分析算法中不可达，也并非立马被回收，一个对象是真正被回收，至少需要经历两次标记过程：如果对象不可达，那它将会被第一次标记并且进行一次筛选，筛选的条件是此对象是否有必要执行 finalize() 方法。当对象没有覆盖 finalize() 方法，或者 finalize() 方法已经被虚拟机调用过，虚拟将将这两种情况都视为“没有必要执行”。
如果这个对象被判定为有必要执行 finalize() 方法，那这个对象将会被放置在一个叫 F-Queue 的队列之中，并在稍后一个由虚拟机自动建立的、低优先级的 Finalizer 线程去执行它。finalize() 方法是对象逃脱回收的最后一次机会，稍后 GC 将对 F-Queue 中的对象进行第二次小规模的标记，如果对象要在 finalize() 中成功拯救自己——只要重新与引用链上的任何一个对象重新建立关联即可。那在第二次标记时他将被移除出“即将回收”的集合；如果对象这时候还没有逃脱，那基本上他就真的被回收了。整个流程图如下
示例代码如下
public class FinalizeEscapeGC {
public static FinalizeEscapeGC SAVE_HOOK = null;
public void isAlive() {
System.out.println("alive.");
}
@Override
protected void finalize() throws Throwable {
super.finalize();
System.out.println("finalize method executed");
FinalizeEscapeGC.SAVE_HOOK = this;
}
public static void main(String[] args) throws InterruptedException {
SAVE_HOOK = new FinalizeEscapeGC();
SAVE_HOOK = null;
System.gc();
Thread.sleep(1000);
if (SAVE_HOOK != null) {
SAVE_HOOK.isAlive();
} else {
System.out.println("dead.");
}
SAVE_HOOK = null;
System.gc();
Thread.sleep(1000);
if (SAVE_HOOK != null) {
SAVE_HOOK.isAlive();
} else {
System.out.println("dead.");
}
}
}
总结
通过本文我们知道当面临 GC 时，哪些对象需要被回收，主要经历以下两个步骤：
- 通过可达性算法分析后对象不可达，
- 两次标记后对象仍没有与引用链上的其他任何对象建立关联。
