深入理解Java虚拟机：垃圾收集

大家好，又见面了，我是你们的朋友全栈君。

概述

    GC即垃圾回收，是指jvm用于释放那些不再使用的对象所占用的内存。

    垃圾收集的目的在于清除不再使用的对象。gc通过确定对象是否被活动对象引用来确定是否收集该对象。两种常用的方法是引用计数和对象引用遍历。

JVM的GC触发原理

    JVM的GC主要是对堆内存的回收，一般把新生代的GC称为minor GC ，把老年代的GC成为 full GC，所谓full gc会先出发一次minor gc，然后在进行老年代的GC。
    首先向eden区申请分配空间，如果空间够，就直接进行分配，否则进行一次Minor GC。
    minor GC 首先会对Eden区的对象进行标记，标记出来存活的对象。然后把存活的对象copy到From空间。
    如果From空间足够，则回收eden区可回收的对象。
    如果from内存空间不够，则把From空间存活的对象复制到To区，
    如果TO区的内存空间也不够的话，则把To区存活的对象复制到老年代。
    如果老年代空间也不够（或者达到触发老年年垃圾回收条件的话）则触发一次full GC。
    简单方向就是Eden->From->To->Old，如下图所示：

引用计数器

    很多教科书判断对象是否存活的算法是这样的：给对象添加一个引用计数器，每当一个地方引用它时，计数器值就加 1；当引用实效后，计数器值就减 1；任何时刻计数器为 0 的对象就是不可能再被使用的；
    但是，至少主流的 Java 虚拟机里面没有选用引用计数算法来管理内存，其中最主要的原因时它很难解决对象之间相互循环引用的问题。采用可达性分析算法。

    引用计数算法的缺陷

public class ReferenceCountingGC { 
   

    public Object instance = null;

    private static final int _1MB = 1024 * 1024;

    /** * 这个成员属性的唯一意义就是占点内存，以便能再 GC 日志中看清楚是否被回收过 */
    @SuppressWarnings("unused")
    private byte[] bigSize = new byte[2 * _1MB];

    public static void main(String[] args) {
        ReferenceCountingGC objA = new ReferenceCountingGC();
        ReferenceCountingGC objB = new ReferenceCountingGC();
        objA.instance = objB;
        objB.instance = objA;

        objA = null;
        objB = null;

        /* 实际上这两个对象已经不可能在被访问了，但是因为他们互相引用着对象， 导致他们的引用计数器都不为0,于是引用计数算法无法通知 GC 收集器回收它们。 384K->0K(76800K) 虚拟机以回收 */
        System.gc();
    }

}

    运行结果

[GC [PSYoungGen: 6738K->384K(76800K)] 6738K->384K(251392K), 0.0014240 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
[Full GC [PSYoungGen: 384K->0K(76800K)] [ParOldGen: 0K->282K(174592K)] 384K->282K(251392K) [PSPermGen: 2622K->2621K(21504K)], 0.0095460 secs] [Times: user=0.02 sys=0.00, real=0.01 secs] 
Heap
 PSYoungGen      total 76800K, used 1981K [0x00000007aaa80000, 0x00000007b0000000, 0x0000000800000000)
  eden space 66048K, 3% used [0x00000007aaa80000,0x00000007aac6f688,0x00000007aeb00000)
  from space 10752K, 0% used [0x00000007aeb00000,0x00000007aeb00000,0x00000007af580000)
  to   space 10752K, 0% used [0x00000007af580000,0x00000007af580000,0x00000007b0000000)
 ParOldGen       total 174592K, used 282K [0x0000000700000000, 0x000000070aa80000, 0x00000007aaa80000)
  object space 174592K, 0% used [0x0000000700000000,0x00000007000469b8,0x000000070aa80000)
 PSPermGen       total 21504K, used 2628K [0x00000006fae00000, 0x00000006fc300000, 0x0000000700000000)
  object space 21504K, 12% used [0x00000006fae00000,0x00000006fb0912f0,0x00000006fc300000)

可达性分析算法

    在主流的商用程序语言中（Java、C#，甚至包括古老的 Lisp）的主流实现中，都是称通过可达性分析（Reachability Analysis）来判定对象是否存活的。这个算法的基本思路就是通过一系列的称为 “GC Roots” 的对象作为起始点，从这些节点开始向下搜索，搜索所走过的路径称为引用链（Reference Chain），当一个对象到 GC Roots 没有任何引用链相连（用图论的话来说，就是从GC Roots 到这个对象不可达）时，则证明此对象是不可用的。

    在Java语言中，可作为 GC Roots 的队形包括下面几种：

• 虚拟机栈（帧栈中的本地变量表）中引用的对象。
• 方法区中类静态属性引用的对象。
• 方法区中常量引用的对象。
• 本地方法栈中 JNI （即一般说的 Native 方法）引用的对象。

引用

    无论通过引用计数算法判断对象的引用数量，还是通过可达性分析算法判断对象的引用链是否可达，判定对象的存活都与 “引用” 有关。在 JDK 1.2 以前，Java 中的引用的定义很传统：如果 reference 类型的数据中存储的数值代表的是另外一块内存的起始地址，就称这块内存代表一个引用。这种定义很存粹，但是太过狭隘，一个对象在这种定义下只有被引用或者没有被引用两种状态，对于如何描述一些 “食之无味，弃之可惜” 的对象就显得无能为力。
    在JDK 1.2 之后，Java 对引用的概念进行了扩充，将引用分为强引用（Strong Reference）、软引用（Soft Reference）、弱引用（Weak Reference）、虚引用（Phantom Reference）4 种，这 4 种引用强度依次逐渐减弱。

• 强引用就是指在程序代码之中普遍存在的，类似 “Object obj = new Object()” 这类的引用，只要强引用还存在，垃圾收集器永远不会回收被引用的对象。
• 软引用是用来描述一些还有用但并非必须的对象。对于软引用关联着的对象，在系统将要发生内存溢出异常之前，将会把这些对象列进回收范围之中进行二次回收。如果这次回收还没足够的内存，才会抛出内存溢出异常。在 JDK 1.2 之后，提供了 SoftReference 类来实现软引用。
• 弱引用也是用来描述非必需对象的，但是它的强度比软引用更弱一些，被弱引用关联的对象只能生存到下一次垃圾收集发生之前。当垃圾收集器工作时，无论当前的内存是否足够，都会回收掉只被弱引用关联的对象。在 JDK 1.2 之后，提供了 WeakRefernce 类来实现弱引用。
• 虚引用也被称为幽灵引用或者幻影引用，它是最弱的一种引用关系。一个对象是否有虚引用的存在，完全不会对其生存时间构成影响，也无法通过虚引用来取得一个对象实例。为一个对象设置虚引用关联的唯一木的就是能在这个对象被收集器回收时收到一个系统通知。在 JDK 1.2 之后，提供了 SoftReference 类来实现虚引用。

生存还是死亡

    即使在可达性分析算法中不可达的对象，也并非是 “非死不可” 的，这时候它们暂时处于 “缓刑” 阶段，要真正宣告一个对象死亡，至少要经历两次标记过程：如果对象在进行可达性分析后发现没有与 GC Roots 相连接的引用链，那它将会被第一次标记并且进行一次筛选，筛选的条件是此对象是否有必要执行 finalize() 方法。当对象没有覆盖 fianlize() 方法，或者 fianlize() 方法已经被虚拟机调用过，虚拟机将这两种情况都视为 “没有必要执行”。
    如果这个对象被判定为有必要执行 fianlize() 方法，那么这个对象将会放置在一个叫做 F-Queue 的队列中，并在稍后由一个虚拟机自动建立的、低优先级的 Finalizer 线程去执行。这里所谓的 “执行” 是指虚拟机会触发这个方法，但并不会承诺会等待它结束，这样做的原因是，如果一个对象在 fianlize() 方法中执行缓慢，或者发生了死循环（更极端的情况），将很可能导致 F-Queue 队列中其他对象永久处于等待，甚至导致整个内存回收系统崩溃。

    一次对象自我拯救的演示：

/** * 此代码演示了两点： * 1.对象可以在被 GC 时自我拯救 * 2.这种自救的机会只有一次，因为一个对象的 fianlize() 方法最多会被系统自动调用一次 * * @author rocki * */
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 method executed!");
        FinalizeEscapeGC.SAVE_HOOk = this;
    }

    public static void main(String[] args) throws Exception {
        SAVE_HOOk = new FinalizeEscapeGC();

        // 对象第一次成功拯救自己
        SAVE_HOOk = null;
        System.gc();
        // 因为 finalize 方法优先级很低，所以要暂停0.5秒以等待它
        Thread.sleep(500);
        if (SAVE_HOOk != null)
            SAVE_HOOk.isAlive();
        else
            System.out.println("no,i am dead : (");

        // 这一段代码与上面的完全相同，但是这次自救却失败了
        SAVE_HOOk = null;
        System.gc();
        // 因为 finalize 方法优先级很低，所以要暂停0.5秒以等待它
        Thread.sleep(500);
        if (SAVE_HOOk != null)
            SAVE_HOOk.isAlive();
        else
            System.out.println("no,i am dead : (");

    }

}

    运行结果：

finalize method executed! yes,i am still alive no,i am dead : (

回收方法区

    很多人认为方法区（或者 HotSpot 虚拟机中的永久代）是没有垃圾收集的，Java 虚拟机规范中确实说过可以不要求虚拟机在方法区实现垃圾手气，而且在这个方法区中进行垃圾收集的 “性价比” 一般比较低：在堆中，尤其是在新生代中，常规应用进行一次垃圾收集一般可以回收 70% ~ 95% 的空间，而永久代的垃圾收集效率远低于此。
    永久代中的垃圾收集主要回收两部分内容：废弃常量和无用的类。回收废弃常量与回收 Java 堆中的对象非常类似。假如一个字符串 “abc” 已经进入了常量池中，但是当前系统没有任何一个 String 对象引用常量池中的 “abc” 常量，如果这是发生内存回收，而且必要的话，这个 “abc” 常量就会被系统清理出常量池。
    判定一个常量是否是 “废弃常量” 比较简单，而要判定一个类是否是 “无用的类” 的条件则相对比较苛刻许多。类需要同时满足下面 3 个条件：

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

标记-清除算法

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

复制算法

    为了解决Mark-Sweep算法的缺陷，Copying算法就被提了出来。它将可用内存按容量划分为大小相等的两块，每次只使用其中的一块。当这一块的内存用完了，就将还存活着的对象复制到另外一块上面，然后再把已使用的内存空间一次清理掉，这样一来就不容易出现内存碎片的问题。具体过程如下图所示：

    这种算法虽然实现简单，运行高效且不容易产生内存碎片，但是却对内存空间的使用做出了高昂的代价，因为能够使用的内存缩减到原来的一半。

    很显然，Copying算法的效率跟存活对象的数目多少有很大的关系，如果存活对象很多，那么Copying算法的效率将会大大降低。

Mark-Compact（标记-整理）算法

    为了解决Copying算法的缺陷，充分利用内存空间，提出了Mark-Compact算法。该算法标记阶段和Mark-Sweep一样，但是在完成标记之后，它不是直接清理可回收对象，而是将存活对象都向一端移动，然后清理掉端边界以外的内存。具体过程如下图所示：

Generational Collection（分代收集）算法

    分代收集算法是目前大部分JVM的垃圾收集器采用的算法。它的核心思想是根据对象存活的生命周期将内存划分为若干个不同的区域。一般情况下将堆区划分为老年代（Tenured Generation）和新生代（Young Generation），老年代的特点是每次垃圾收集时只有少量对象需要被回收，而新生代的特点是每次垃圾回收时都有大量的对象需要被回收，那么就可以根据不同代的特点采取最适合的收集算法。

    目前大部分垃圾收集器对于新生代都采取Copying算法，因为新生代中每次垃圾回收都要回收大部分对象，也就是说需要复制的操作次数较少，但是实际中并不是按照1：1的比例来划分新生代的空间的，一般来说是将新生代划分为一块较大的Eden空间和两块较小的Survivor空间，每次使用Eden空间和其中的一块Survivor空间，当进行回收时，将Eden和Survivor中还存活的对象复制到另一块Survivor空间中，然后清理掉Eden和刚才使用过的Survivor空间。

    而由于老年代的特点是每次回收都只回收少量对象，一般使用的是Mark-Compact算法。

垃圾收集器

堆的新生代和老年代
垃圾收集器

GC日志说明：

    打印 GC 日志，-XX:+PrintGCDetails(Run Configuration—>Arguments)

    GC打印时间: [垃圾回收类型回收时间: [收集器名称: 年轻代回收前占用大小->年轻代回收后占用大小(年轻代当前容量),年轻代局部GC时JVM暂停处理的时间] 堆空间GC前占用的空间->堆空间GC后占用的空间(堆空间当前容量),GC过程中JVM暂停处理的时间]。

    垃圾回收类型：分为GC和Full GC.

    GC一般为堆空间某个区发生了垃圾回收，

    Full GC基本都是整个堆空间及持久代发生了垃圾回收，通常优化的目标之一是尽量减少GC和Full GC的频率。

    收集器名称：一般都为收集器的简称或别名，通过收集器名称基本都能判断出那个区发生了GC。

    DefNew：年轻代（新生代）发生了GC （若为DefNew可知当前JVM年轻代使用的串行收集器）

    ParNew：年轻代（新生代）发生了GC （若为ParNew可知当前JVM年轻代使用了并行收集器）

    Tenured：老年代发生了GC

    Perm：持久代发生了GC