JVM学习总结（三）——对象存活判定算法的两种实现

垃圾收集器在对堆内存进行回收前&＃xff0c;第一件事情就是要确定这些堆中的对象哪些还“存活”着&＃xff0c;哪些已经“死去”&＃xff08;“死去”即不可能再被任何途径使用的对象&＃xff09;了。

1、引用计数算法

引用计数算法&＃xff08;Reference Counting&＃xff09;&＃xff1a; 在对象中添加一个引用计数器&＃xff0c;每当有一个地方引用它时&＃xff0c;计数器值就加一&＃xff1b;当引用失效时&＃xff0c;计数器值就减一&＃xff1b;任何时刻计数器为零的对象就是不可能再被使用的。
优点&＃xff1a; 引用计数算法&＃xff08;Reference Counting&＃xff09;虽然占用了一些额外的内存空间来进行计数&＃xff0c;但它的原理简单&＃xff0c;判定效率也很高在大多数情况下它都是一个不错的算法。
缺点&＃xff1a; 主流的Java虚拟机里面都没有选用引用计数算法来管理内存&＃xff0c;主要原因是&＃xff0c;这个看似简单的算法有很多例外情况要考虑&＃xff0c;必须要配合大量额外处理才能保证正确地工作&＃xff0c;譬如单纯的引用计数就很难解决对象之间相互循环引用的问题。

2、可达性分析算法

可达性分析算法&＃xff08;Reachability Analysis&＃xff09;: 通过一系列称为“GC Roots”的根对象作为起始节点集&＃xff0c;从这些节点开始&＃xff0c;根据引用关系向下搜索&＃xff0c;搜索过程所走过的路径称为“引用链”&＃xff08;Reference Chain&＃xff09;&＃xff0c;如果某个对象到GC Roots间没有任何引用链相连&＃xff0c;或者用图论的话来说就是从GC Roots到这个对象不可达时&＃xff0c;则证明此对象是不可能再被使用的。
Java的内存管理子系统正是通过可达性分析算法来判定对象是否存活的。利用可达性分析算法判定对象是都可回收如下图&＃xff1a;

在Java技术体系里面&＃xff0c;固定可作为GC Roots的对象包括以下几种&＃xff1a;

1. 在虚拟机栈&＃xff08;栈帧中的本地变量表&＃xff09;中引用的对象&＃xff0c;譬如各个线程被调用的方法堆栈中使用到的参数、局部变量、临时变量等。
2. 在方法区中类静态属性引用的对象&＃xff0c;譬如Java类的引用类型静态变量。
3. 在方法区中常量引用的对象&＃xff0c;譬如字符串常量池&＃xff08;String Table&＃xff09;里的引用。
4. 在本地方法栈中JNI&＃xff08;即通常所说的Native方法&＃xff09;引用的对象。
5. Java虚拟机内部的引用&＃xff0c;如基本数据类型对应的Class对象&＃xff0c;一些常驻的异常对象&＃xff08;比如NullPointException、OutOfMemoryError&＃xff09;等&＃xff0c;还有系统类加载器。
6. 所有被同步锁&＃xff08;synchronized关键字&＃xff09;持有的对象。
7. 反映Java虚拟机内部情况的JMXBean、JVMTI中注册的回调、本地代码缓存等。

除了这些固定的GC Roots集合以外&＃xff0c;根据用户所选用的垃圾收集器以及当前回收的内存区域不同&＃xff0c;还可以有其他对象“临时性”地加入&＃xff0c;共同构成完整GC Roots集合。譬如分代收集和局部回收&＃xff08;Partial GC&＃xff09;&＃xff0c;如果只针对Java堆中某一块区域发起垃圾收集时&＃xff08;如最典型的只针对新生代的垃圾收集&＃xff09;&＃xff0c;必须考虑到内存区域是虚拟机自己的实现细节&＃xff08;在用户视角里任何内存区域都是不可见的&＃xff09;&＃xff0c;更不是孤立封闭的&＃xff0c;所以某个区域里的对象完全有可能被位于堆中其他区域的对象所引用&＃xff0c;这时候就需要将这些关联区域的对象也一并加入GC Roots集合中去&＃xff0c;才能保证可达性分析的正确性。

即使在可达性分析算法中判定为不可达的对象&＃xff0c;也不是“非死不可”的&＃xff0c;这时候他们暂时处于“缓刑”阶段&＃xff0c;要真正宣告一个对象死亡&＃xff0c;至少要经历两次标记过程&＃xff1a;

1. 如果对象在进行可达性分析后发现没有与GC Roots相连接的引用链&＃xff0c;那它将会被第一次标记。
2. 随后进行一次筛选&＃xff0c;筛选的条件是此对象是否有必要执行finalize()方法。 假如对象没有覆盖finalize()方法&＃xff0c;或者finalize()方法已经被虚拟机调用过&＃xff0c;那么虚拟机将这两种情况都视为“没有必要执行”。如果这个对象被判定为确有必要执行finalize()方法&＃xff0c;那么该对象将会被放置在一个名为F-Queue的队列之中&＃xff0c;并在稍后由一条由虚拟机自动建立的、低调度优先级的Finalizer线程去执行它们的finalize()方法。这里所说的“执行”是指虚拟机会触发这个方法开始运行&＃xff0c;但并不承诺一定会等待它运行结束。这样做的原因是&＃xff0c;如果某个对象的finalize()方法执行缓慢&＃xff0c;或者更极端地发生了死循环&＃xff0c;将很可能导致F-Queue队列中的其他对象永久出于等待&＃xff0c;甚至导致整个内存回收子系统的崩溃。
   finalize()方法是对象逃脱死亡命运的最后一次机会&＃xff0c;稍后收集器将对F-Queue中的对象进行第二次小规模的标记&＃xff0c;如果对象要在finalize()中成功拯救自己——只要重新与引用链上的任何一个对象建立关联即可&＃xff0c;譬如把自己&＃xff08;this关键字&＃xff09;赋值给某个类变量或者对象的成员变量&＃xff0c;那在第二次标记时它将被移出“即将回收”的集合&＃xff1b;如果对象这时候还没有逃脱&＃xff0c;那基本上它就真的要被回收了。

注&＃xff1a;

3. 任何一个对象的finalize()方法都只会被系统自动调用一次。
4. 建议尽量避免使用finalize()方法&＃xff0c;因为它的运行代价高昂&＃xff0c;不确定性大&＃xff0c;无法保证各个对象的调用顺序&＃xff0c;如今已被官方明确声明为不推荐使用的语法。finalize()能做的所有工作&＃xff0c;使用try-finally或者其他方式都可以做得更好、更及时。

方法区的垃圾收集主要回收两部分内容&＃xff1a;废弃的常量和不再使用的类型。

1. 回收废弃常量与回收Java堆中的对象非常类似。例如常量池中字面量的回收——假如一个字符串“java”曾经进入常量池中&＃xff0c;但是当前系统又没有任何一个字符串对象的值是“java”&＃xff0c;换句话说&＃xff0c;已经没有任何字符串对象引用常量池中“java”常量&＃xff0c;且虚拟机中也没有其他地方引用这个字面量。如果在这时发生内存回收&＃xff0c;而且垃圾收集器判断确有必要的话&＃xff0c;这个“java”常量就将会被系统清理出常量池。常量池中其他类&＃xff08;接口&＃xff09;、方法、字段的符号引用也与此类似。

2. 判定一个类型是否属于“不再被使用的类”需要同时满足下面三个条件&＃xff1a;

   • 该类所有的实例都已经被回收&＃xff0c;也就是Java堆中不存在该类及其任何派生子类的实例。
   • 加载该类的类加载器已经被回收&＃xff0c;这个条件除非是经过精心设计的可替换类加载器的场景&＃xff0c;如OSGi、JSP的重加载等&＃xff0c;否则通常是很难达成的。
   • 该类对应的java.lang.Class对象没有在任何地方被引用&＃xff0c;无法在任何地方通过反射访问该类的方法。

参考&＃xff1a;深入理解Java虚拟机&＃xff1a;JVM高级特性与最佳实践&＃xff08;第3版&＃xff09; 周志明