判断对象是否可回收、垃圾回收算法

介绍下判断对象是否都能回收的两种方式：引用计数法、可达性分析，另外会介绍一下常用的垃圾回收算法：标记清除算法，复制算法，标记整理算法，分代回收算法。

对象是否可回收

我们谈论的垃圾收集（Garbage Collection，GC）主要是针对Java堆内存的回收，而堆里面主要存放的就是对象，那么如果判断对象是否能够被回收呢？主要有两种方式：引用计数法和可达性分析，下面我们分别介绍一下：

引用计数算法

引用计数法（Reference Counting）：给对象中添加一个引用计数器，每当有一个地方引用它时，计数器就加1；当引用失效时，计数器就减1；当计数器为0时对象就是不再被使用的。这种方式实现简单，但是主流垃圾收集器没有用这种方式管理内存的，因为这种方式很难解决循环依赖问题。下面举个例子：执行时设置JVM参数（开发工具Eclipse和Idea都是可以设置的）为 -XX:+PrintGCDetails，用来打印垃圾收集的日志信息

/** * -XX:+PrintGCDetails */public class ReferenceCountGC {     private Object instance=null;     private static final int _1MB=1024*1024;     private byte[] bytes=new byte[2*_1MB];     public static void main(String args[]){        ReferenceCountGC objA = new ReferenceCountGC();        ReferenceCountGC objB = new ReferenceCountGC();        objA.instance=objB;        objB.instance=objA;         objA=null;        objB=null;         System.gc();    }}

运行后控制台输出如下：我们看到垃圾收集时并没有因为两个对象相互引用就不回收它们，说明我们的JVM并没有采用引用计数法（我使用的是JDK1.8，不同的版本GC日志会有差异）。

[GC (System.gc()) [PSYoungGen: 9258K->952K(75264K)] 9258K->960K(247296K), 0.0018260 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] [Full GC (System.gc()) [PSYoungGen: 952K->0K(75264K)] [ParOldGen: 8K->831K(172032K)] 960K->831K(247296K), [Metaspace: 3396K->3396K(1056768K)], 0.0219141 secs] [Times: user=0.06 sys=0.01, real=0.02 secs] Heap PSYoungGen      total 75264K, used 1935K [0x000000076c380000, 0x0000000771780000, 0x00000007c0000000)  eden space 64512K, 3% used [0x000000076c380000,0x000000076c563ef8,0x0000000770280000)  from space 10752K, 0% used [0x0000000770280000,0x0000000770280000,0x0000000770d00000)  to   space 10752K, 0% used [0x0000000770d00000,0x0000000770d00000,0x0000000771780000) ParOldGen       total 172032K, used 831K [0x00000006c4a00000, 0x00000006cf200000, 0x000000076c380000)  object space 172032K, 0% used [0x00000006c4a00000,0x00000006c4acff38,0x00000006cf200000) Metaspace       used 3440K, capacity 4496K, committed 4864K, reserved 1056768K  class space    used 380K, capacity 388K, committed 512K, reserved 1048576K

可达性分析算法

可达性分析（Reachability Analysis）：通过一系列的称为 "GC Roots" （GC根）的对象作为起点，从这些节点开始向下搜索，搜索所走过的路径称为引用链（Reference Chain），当一个对象到GC Roots没有任何引用链相连（就是从GC Roots到对象不可达）时，则证明此对象是不可用的，主流的开发语言都是使用的这种方式判断对象是否存活的。如下图所示，object5，object6，object7虽然相互关联，但是GC Roots是不可达的，所以这些对象是可回收的。

image

Java中可以作为GC Roots的对象主要有：

• 虚拟机栈（栈帧中的本地变量表）中引用对象
• 方法区中的类静态属性引用的对象
• 方法区中常量引用的对象
• 本地方法栈JNI的引用对象
• 激活状态的线程
• 正在被用于同步的各种锁对象
• Class 由系统类加载器(system class loader)加载的对象，这些类不可以被回收，他们可以以静态字段的方式持有其它对象

对象从生存到死亡

对象从生到死会经历两次标记过程，当对象与GC Roots不可达时，会先做一次标记，然后判断对象有没有覆盖finalize()方法或者finalize()方法已经被虚拟机调用过（finalize()方法可以拯救一次对象），如果这两种情况有一种成立则不会回收。如果前面的情况不成立则会将对象放入F-Queue队列中，由一个虚拟机自动建立的低优先级的Finalizer线程去取队列中的对象执行finalize()方法。如果对象能重新与GC Roots建立关系，则对象可以不被回收，如果不能建立关系则进行第二次标记，随后被回收。

注意：虽然finalize()方法可以拯救一次对象，但是该方法不建议使用。

image.png

回收方法区

方法区也需要具备垃圾回收的功能，只不过方法区回收的效果不像堆中那么明显，如果应用中大量使用反射、动态代理、CGLib等字节码框架可能会导致方法区内存溢出。方法区主要回收废弃常量和无用的类型。回收常量例如常量池中的字面量，假如一个字符串"abc"进入常量池，但是没有对象引用常量池中的"abc"，如果此时进行内存回收，这个常量会被回收掉。回收类比较麻烦，判断一个类是无用的条件：

1. 该类在堆中所有的实例都已经被回收

2. 加载该类的ClassLoader已经被回收

3. 该类对应的java.lang.Class对象没有在任何地方被引用，无法在任何地方通过反射访问该类的方法

满足以上三个条件的类可以但并不一定被回收，是否对类进行回收，HotSpot虚拟机提供了 -Xnoclassgc 参数进行控制，还可以使用 -verbose:class以及-XX:+TraceClassLoading、-XX:+TraceClassUnLoading查看类加载和卸载信息。

垃圾回收算法

标记-清除算法

“标记一清除”（Mark-Sweep）算法，分为“标记”和“清除”两个阶段：首先标记出所有需要回收的对象，在标记完成后统一回收所有被标记的对象。它的主要不足有两个：一个是效率问题，标记和清除两个过程的效率都不高；另一个是空间问题，标记清除之后会产生大量不连续的内存碎片，空间碎片太多可能会导致以后在程序运行过程中需要分配较大对象时，无法找到足够的连续内存而不得不提前触发另一次垃圾收集动作。标记一清除算法是基础算法，后面的算法都是在其基础上改进的，其执行过程如下图所示。

image

复制算法

“复制”(Copying)算法：它将可用内存按容量划分为大小相等的两块，每次只使用其中的一块。当这一块的内存用完了，就将还存活着的对象复制到另外一块上面，然后再把己使用过的内存空间一次清理掉。这样使得每次都是对整个半区进行内存回收，内存分配时也就不用考虑内存碎片等复杂情况，只要移动堆顶指针，按顺序分配内存即可，实现简单，运行高效。其缺点是只能用一半内存，浪费资源。复制算法的执行过程如下图所示：

image

大部分虚拟机都是采用复制算法回收新生代的，研究表明，新生代中的对象98%都是“朝生夕死”的，所以并不需要按照1：1的比例来划分内存空间。Java虚拟机将新生代内存分为一块较大的Eden空间和两块较小的Survivor（S0和S1）空间，每次使用Eden和其中一块Survivor。当回收时，将Eden和Survivor中还存活着的对象一次性地复制到另外一块Survivor空间上，最后清理掉Eden和刚才用过的Survivor空间。Eden：S0：S1的比例默认是8：1：1，每次新生代中可用内存空间为整个新生代容量的90％（80％+10％)，只有10％的内存会被“浪费”。但是不能保证每次都能回收百分之九十多的对象，当Survivor区内存不够用时需要依赖老年代进行分配担保（Handle Promotion），说白了就是去老年代借内存空间，后面再做介绍。

标记-整理算法

在回收老年代时可能回收后还有很多对象存活，复制算法肯定是不合适的，根据老年代的特点，"标记-整理"（Mark-Compact）算法出现了，标记过程仍然与"标记一清除"算法一样，但后续步骤不是直接对可回收对象进行清理，而是让所有存活的对象都向一端移动，然后直接清理掉端边界以外的内存，如下图所示：

image

分代收集算法

分代收集（Generational Collection）算法是根据对象生存周期的不同，将内存划分为几块。Java堆中是分为新生代和老年代，新生代对象朝生夕死选择复制算法。老年代对象存活率高、没有分配担保，必须采用标记-清除或者标记-整理算法进行回收。

参考：《深入理解Java虚拟机第二版》