在第一篇Java虚拟机学习的文章中，我们已经了解了Java内存运行时区域的各个部分，其中，程序计数器、虚拟机栈、本地方法栈3个区域的生命周期和线程一样，属于线程私有。
这几个区域的内存分配和回收都具有确定性，因为在编译期即可知内存分配的大小，同时，随着方法的结束或者线程的结束，该部分分配的内存也会随之被收回，所以不需要过多考虑回收问题。
而Java堆和方法区则不一样，一个接口中的多个实现类需要的内存可能不一样，一个方法中的多个分支需要的内存也可能不一样，只有程序处于运行期间时才能知道会创建哪些对象。这部分的内存分配和回收都是动态的，垃圾收集器关注的时这部分的内存。
那么，垃圾回收器内存回收的过程是什么呢？
一、判断对象的存活与否
判断对象存活的两种算法
1. 引用计数算法
算法思路：
给对象中添加一个引用计数器，每当有一个地方引用它时，计数器值就加1；当引用失效时，计数器值就减1；任何时刻计数器为0的对象就是不可能再被使用的。
优点：实现简单，判定效率高
缺点：无法解决对象间循环引用的问题，如下代码，它们互相引用对方，导致它们的引用计数器都不为0，竟而无法被回收器回收
public class Test {
public Object instance = null；
public static void testGC() {
Test a = new Test();
Test b = new Test();
a.instance = b;
b.instance = a;
}
}
2. 可达性分析算法
算法思路:
通过一系列被称为“GC Roots”的对象作为起点，从这些节点开始向下搜索，搜索走过的路径称为引用链（Reference Chain），当一个对象到GC Roots没有任何引用链相连时，则证明该对象是不可用的。如下图所示
可达性分析算法判断对象是否可以回收
再Java语言中，可作为GC Roots的对象包括下面几种：
- 虚拟机栈（栈帧中的本地变量表）中引用的对象，即，方法中引用的对象
- 方法区中的静态属性引用的对象
- 方法区中常量引用的对象
- 本地方法栈中Native方法引用的对象
二、对象的回收
通过上面的两种算法，可以明确哪些对象是可以被回收的，但在实际的执行过程中，即便在可达性分析算法中不可达的对象，也并非“非死不可”。
一般宣告一个对象的死亡（可被回收），至少要经历两次标记过程：
-
第一次标记后进行筛选，筛选标准是此对象是否有必要执行finalize()方法，即，对象是否覆写了 finalize（） 方法，如果没有覆写，或者 finalize（） 方法已经被虚拟机调用过，则直接进行第二次标记并被回收。
-
如果对象有覆写finalize 方法，且未被虚拟机调用过，则会将这个对象加入一个叫“F-Queue”的队列中，虚拟机会建立一个低优先级的 Finalizer 线程去执行它，这里说的“执行”是指该线程会去触发 finalize 方法，但是并不会等待 finalize 方法执行完成。主要是因为 finalize 方法的不确定性，它可能要花很长时间才能执行完成，甚至死循环，永远不结束，这将导致整个 GC 工作的异常，甚至崩溃。
-
在 finalize 方法中将自己（this关键字）赋值给某个类变量或对象的成员变量，那么在第二次标记时它将被移出回收的集合，如果对象并未被拯救，则最终被回收。
说明：
-
任何一个对象的finalize() 方法只会被系统自动调用一次，如果一个在 finalize() 被拯救的对象再次需要回收，则它的 finalize() 将不会再被触发了。
-
不建议使用finalize() 方法，它的运行代价高，不确定性大，GC 也不会等待它执行完成，它的功能完全可以被 try-finally 代替。
网友评论