垃圾收集（GC）概述

为什么要垃圾回收

我们知道电脑的内存是有限的，如果一段程序申请了一块内存空间并执行完计算之后，没有释放内存，会导致这块内存被占用，那么可用内存就变少了，如果一个系统很庞大，程序中迟早会把电脑内存耗尽的。为了提高内存的使用效率，内存在使用完必须释放，这样其他程序才可能重新申请这块内存。C语言中有malloc、free等于内存分配以及内存释放的函数。而Java中使用垃圾收集机制来整理内存空间。

垃圾收集的区域

Java的内存区域分为程序计数器、虚拟机栈、本地方法栈、Java堆和方法区，而且其中的程序计数器、虚拟机栈和本地方法栈都是线程独立的，也就是说这三块内存区域的生命周期与线程是同生共死的。栈中帧栈在类结构确定的时候就已经知道该分配多少内存了，所以当线程结束的时候，内存也跟着一起回收了，从这个角度看，这三块的内存区域的内存分配和垃圾收集就比较固定了。反观Java堆和方法区，比如我们定义一个接口，接口有着不同的实现类，而每个实现类的内存可能会不一样，每个实现类的方法的多个语句分支也可能需要的内存不一样。所以这两块区域的内存分配具有不确定性，那么在垃圾回收的时候自然也存在不确定性。

因此，在Java的垃圾收集机制中，关注的是Java堆和方法区这两块内存区域的垃圾回收。

对象存活还是死去

引用计数法

给对象添加一个引用计数器，每当有一个地方引用它时，计数器值就加1，当引用失效时，计数器值就减1，任何时刻计数器为0的对象就是不可能再被使用的。

优点：引用计数算法的实现简单，判定效率也很高，在大部分情况下它都是一个不错的选择
缺点：Java虚拟机并没有选择这种算法来进行垃圾回收，主要原因是它很难解决对象之间的相互循环引用问题，例如下面的代码所示：

public class ReferenceCountingGC {
     public Object instance = null;
     private static final int _1MB = 1024 * 1024;
     // 这个成员属性的唯一意义就是占点内存，以便在能在GC日志中看清楚是否有回收过
     private byte[] bigSize = new byte[2 * _1MB];
     public static void testGC() {
         ReferenceCountingGC objA = new ReferenceCountingGC();
         ReferenceCountingGC objB = new ReferenceCountingGC();
         objA.instance = objB;
         objB.instance = objA;
         objA = null;
         objB = null;
         // 假设在这行发生GC，objA和objB是否能被回收？
         System.gc();
     }
}

实际上这两个对象已经不可能再被访问，但是因为它们互相引用着对方，导致它们的引用计数值都不为0，引用计数算法无法通知GC收集器回收它们。

可达性分析算法

主流的商用程序语言（Java，C#）的主流实现中，都是通过可达性分析（Reachability Analysis）来判定对象是否存活的。

算法的基本思想就是通过一系列的称为“GC Roots”的对象作为起始点，从这些起始点开始向下搜索，所走过的路径称为引用链，如果一个对象到GC Roots没有任何引用链，那么这个对象是不可用的，就是说，程序中没有谁引用了这个对象，所以可以说从根节点到叶子结点是不可达的。

Java中，以下对象可作为GC Roots对象：

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

对象finalize()方法的自我拯救

注意，即使在可达性分析算法中判定为可回收的对象（不可达），也并非是“非死不可”的。

原因在于要宣告一个对象的死亡，需要两次标记，如果一个对象没有与GC Roots结点相连，就会被第一次标记，并且进行一次筛选：此对象是否有必要执行finalize()方法。如果对象没有覆盖finalize()方法，或者该方法已经为JVM调用过了，则“没有必要执行”finalize()方法。如果对象覆盖了finalize方法，并且在finalize方法中与某个对象建立了引用关系例如把this关键字（自己）赋值给某个类变量或者对象的成员变量（GC Roots），那么第二次标记会失败，那么这个对象就会被移出“即将回收”的对象列表，移出之后这个对象就“活”了下来，如果在finalize方法中这个对相关仍然没有与一个对象建立引用关系，那么这个对象就真正死亡了。

下面的代码展示了自我拯救成功与失败的过程：

package com.jvm.GC;

public class FinalizeEscapeGC {
    public static FinalizeEscapeGC SAVE_HOOK = null;

    public void isAlive() {
        System.out.println("yes, i am still alive :)");
    }

    @Override
    protected 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();
        // 因为Finalizer方法优先级很低，暂停0.5秒，以等待它
        Thread.sleep(500);
        if (SAVE_HOOK != null) {
            SAVE_HOOK.isAlive();
        } else {
            System.out.println("no, i am dead :(");
        }

        // 下面这段代码与上面的完全相同，但是这次自救却失败了
        // 因为finalize()已经执行过了，只调用一次
        SAVE_HOOK = null;
        System.gc();
        // 因为Finalizer方法优先级很低，暂停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 :(

注意：finalize()的运行代价高昂，不确定性大，无法保证各个对象的调用顺序，应该尽量避免使用。

回收方法区

前面说了，Java的内存回收主要实在方法区和Java堆中，Java堆中的新生代，因为新生代的存活时间比较短，所以对新生代进行垃圾回收回收的空间比较大，但是方法区中的永久代则由于可能存活时间较长，所以下一次的垃圾回收回收该对象的可能性没有新生代那么大。所以对永久代的回收效率会大打折扣。但是这部分对象仍然是需要回收。

永久代的垃圾回收包括两部分：废弃常量和无用的类

废弃常量的回收比较好理解，因为只要没有任何对象引用常量池中的某个对象，那么这个对象就会被回收。前面说的是非常量池中的对象，废弃常量回收的是运行时常量池中的对象，所以只需要一次标记就好。

无用的类回收需要满足以下三个条件才可以宣判一个类的“死刑”：

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

注意上面的“可以”而非“必然”。与对象的回收不同，是否需要对类进行回收，需要设置相关的参数才行。

在大量使用反射、动态代理、CGLib等ByteCode框架、动态生成JSP以及OSGi这类频繁自定义ClassLoader的场景都需要虚拟机具备类卸载的功能，以保证永久代不会溢出。

参考
1、周志明，深入理解Java虚拟机：JVM高级特性与最佳实践，机械工业出版社

原文：https://blog.csdn.net/u011080472/article/details/51322855