JVM学习之垃圾回收和垃圾回收器

目录

背景

概述

垃圾定义

为何需要GC

早期垃圾回收

Java的垃圾回收机制

相关算法

标记阶段：引用计数算法

标记阶段：可达性分析算法

对象的finalization机制

使用MAT进行GC Roots溯源

清除阶段：标记-清除算法

清除阶段：复制算法

清除阶段：标记-压缩算法

小结

分代收集算法

增量收集算法、分区算法

增量收集算法

分区算法

相关概念

System.gc()的理解

内存溢出与内存泄漏

内存溢出(OOM)

内存泄漏

Stop The World

垃圾回收的并行与并发

安全点与安全区域

安全点

安全区域

实际执行

强引用

软引用

弱引用

虚引用

终结器引用

垃圾回收器

GC分类与性能指标

分类

性能指标

吞吐量

暂停时间

不同的垃圾回收器概述

Serial回收器：串行回收

ParNew回收器：并行回收

Parallel回收器：吞吐量优先

CMS回收器：低延迟

G1回收器：区域化分代式

分区算法的特点

参数设置

区域Region：化整为零

简要回收过程

记忆集与写屏障

详细回收过程

优化建议

垃圾回收器总结

GC日志分析

垃圾回收器的新发展

EpsilonGC

Shenadoah GC

ZGC

其他GC

结语

---

背景

迟迟不开学，赋闲多日，学习新东西以打发时间，现在整理下JVM的最后一部分笔记——垃圾回收和垃圾回收器

概述

垃圾定义

进程中没有任何指针指向的对象，是为垃圾

为何需要GC

为了方便JVM整理出内存分配给新的对象，不进行GC的话，内存迟早要被消耗完。

早期垃圾回收

C阶段，使用malloc、realloc、calloc函数申请内存，使用free函数释放内存

C++阶段，使用new关键字申请内存，使用delete关键字释放内存

Java的垃圾回收机制

Java的自动内存管理，可以降低内存泄漏和溢出的风险，让程序员更专注业务开发

GC作用区域是堆和方法区，频繁回收新生代，较少收集老年代，基本不动方法区

相关算法

垃圾回收分为标记-清除两阶段，第一阶段标记需要回收的对象，第二阶段对这些对象进行回收

标记阶段：区分出哪些对象是存活对象，哪些是死亡的对象，死亡的定义是不被任何对象继续引用

标记阶段：引用计数算法

对每个对象都保存一个整型的引用计数器属性，记录对象被引用的情况

如果任何一个对象引用了对象A，则A的引用计数器+1，如果引用失效了，计数器就-1

如果A的引用计数器值为0，则A不可能再被使用，可进行回收

 

优点：

1）、实现简单，垃圾对象便于标识

2）、判断效率高，回收没有延迟

 

缺点：

1）、需要单独的字段存储计数器增加了存储空间开销；

2）、每次赋值都要更新计数器，伴随着加法减法操作，增加了时间开销；

3）、无法处理循环引用的情况，这一点直接导致java的垃圾回收器里没有使用这种算法

 

循环引用：

对于以下循环链表，p指针指向头结点，尾结点的next对象指向头结点，这种情况就是循环引用

将p置为null，头结点的计数器-1，值为1，导致不能被回收，从而发生内存泄漏

 

 

虽然java没有使用引用计数，但python用了，但也对其进行了优化：

1）、手动解除：在合适的时机，解除引用关系

2）、使用弱引用weakref，这是python提供的标准库，旨在解决循环引用

标记阶段：可达性分析算法

基本思路：

1）、可达性分析是以根对象集合(GC Roots)为起始点，按照从上至下的方式搜索被根对象集合所连接的目标是否可达

2）、使用可达性分析算法后，内存中的存活对象都会被根对象集合直接或间接连接着，搜索走过的路径称之为引用链

3）、如果目标对象没有任何引用链相连，则是不可达的，意味着此对象已经死亡，可以被标记为垃圾对象

4）、在可达性分析算法中，只有能被根对象集合直接或间接连接的对象才是存活对象

GC Roots包含以下几类元素：

1）、栈中引用的对象(局部变量表)，虚拟机栈或本地方法栈

2）、方法区中类的静态属性引用的对象

3）、方法区中常量引用的对象

4）、同步锁syncronized持有的对象

5）、JVM内部的引用：Class对象、常驻异常对象、系统类加载器

6）、反应JVM内部情况的JMXBean、JVMTI中注册的回调、本地代码缓存等

 

如果一个指针指向了堆内存(元空间外)的对象，而自己又不在堆内存(元空间外)里面，那他就是一个GC Root

 

除了以上常规的GC Roots集合外，根据用户所选的垃圾回收器以及当前回收的内存区域的不同(方法区)，还可以将其他对象临时性加入，共同构成完整的根对象集合。比如分代收集和局部回收。

如果只针对堆中某一块区域进行垃圾回收(比如只针对新生代)，就必须考虑内存区域的实现细节，因为这个区域的对象完全有可能被其他区域的对象所引用，这是就需要一并将关联区域的对象也加入根结点集合，才能保证可达性分析的准确性。

 

注意，如果使用可达性分析来判断内存是否可回收，就必须在一个能保证一致性的快照中进行分析工作，这样才能保证分析结果的准确性，所以GC时必须Stop The World暂停用户线程

对象的finalization机制

在回收某对象之前，总会先调用这个对象的finalize()方法，我们可以覆写此方法，用于在对象被回收时进行资源释放等收尾工作

 

永远不要主动调用某对象的finalize()方法，原因有三：

1）、在finalize()时，可能会导致对象复活

2）、finalize()方法执行时间是没有保障的，完全由GC线程决定。一个极端条件下，则此方法没有执行机会

3）、如果finalize()方法写的不好，会严重影响GC性能

 

由于finalize()方法的存在，虚拟机中的对象一般处于三种可能的状态：

1）、可触及的：从根结点开始，可以到达这个对象

2）、可复活的：对象的所有引用都被释放，但是对象有可能在finalize()方法中复活

3）、不可触及的：对象的finalize()方法被调用，且没有复活，那么就会进入不可触及状态。不可触及的对象不可能被复活，因为finalize()方法只会被调用一次

 

判断一个对象objA是否可回收，至少要经历两次标记过程：

1）、如果objA到根结点集合没有引用链，则进行第一次标记

2）、进行筛选，看此objA是否有必要执行finalize()方法

    a.如果此对象没有覆写finalize()方法，或者finalize()方法已经被虚拟机调用过，则虚拟机视为没有必要执行，objA被判定为不可触及的

    b.如果对象覆写了finalize()方法，且没有被执行过，那么objA会被插入到F-Queue队列中。这是一个由虚拟机自动创建的、低优先级的Finalizer线程，此线程会触发objA的finalize()方法去执行

    c.finalize()方法是对象逃脱死亡的最后机会，稍后GC会对F-Queue中的对象进行第二次标记。如果objA在finalize()方法中与引用链上的任何一个对象建立了联系，那么第二次标记时，objA会被移出“即将回收”集合。之后，如若对象再次出现没有引用存在的情况，此时，finalize()方法不会再被调用，对象会直接变成不可触及的对象，换言之，finalize()方法只会被调用一次

 

所以只有在对象不可触及时才会被回收

 

对于对象在finalize()方法中复活的代码演示

package jvm.gcDemos;

public class RebornObj {
    public static RebornObj obj;


    public static void main(String[] args) throws InterruptedException {
        obj = new RebornObj(); // 在堆空间中new一个RebornObj对象，并让元空间的obj指针指向它
        obj = null;
        System.gc(); // 第一次gc，堆中对象的finalize()方法被调用
        System.out.println("第一次gc");


        Thread.sleep(2000);


        if (obj == null) {
            System.out.println("obj is dead");
        } else {
            System.out.println("obj is still alive");
        }


        obj = null;
        System.gc(); // 第二次gc，堆中对象的finalize()方法不会被调用
        System.out.println("第二次gc"); 


        if (obj == null) {
            System.out.println("obj is dead");
        } else {
            System.out.println("obj is still alive");
        }
    }


    @Override
    protected void finalize() throws Throwable {
        super.finalize();
        System.out.println("待回收对象的finalize方法被调用");
        obj = this;
    }
}

控制台输出

待回收对象的finalize方法被调用
第一次gc
obj is still alive
第二次gc
obj is dead


Process finished with exit code 0

使用MAT进行GC Roots溯源

1）、首先下载MAT，可访问官网https://www.eclipse.org/mat/

下载后直接解压，打开里面的MemoryAnalyzer.exe就能用

2）、编写样例代码

package jvm.gcDemos;


import java.util.ArrayList;
import java.util.Date;
import java.util.Scanner;


public class GCRoots {
    public static void main(String[] args) {
        ArrayList strings = new ArrayList();
        Date date = new Date();


        for (int i = 0; i < 100; i++) {
            strings.add(String.valueOf(i));
            try {
                Thread.sleep(30);
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
        }


        System.out.println("添加数据结束，请指示：");
        new Scanner(System.in).next();


        strings = null;
        date = null;


        System.out.println("数据已置空，请结束：");
        new Scanner(System.in).next();
        System.out.println("结束");


    }
}

3）、运行以上代码，会阻塞在第一次控制台输入，此时打开jvisualvm，对此进程的堆进行快照。关于jvisualvm的简单使用，可以参见文章JVM学习笔记之堆的核心概述部分

会在左侧出现新建好的快照

右击它，选择保存的目录，点击确定即可

 

然后在控制台输入指令，让程序释放strings和date引用，此时会阻塞在第二次控制台输入，然后重复上面操作，生成第二个快照文件并保存，最后在控制台随便输入文字，让程序结束即可

关闭jvisualvm后，在我们指定的目录下，会有生成的两个快照文件

其他文件都是我之前用mat分析快照文件时生成的

4）、用mat打开比较老的hprof文件，点击中间窗口中类似数据库的图标，点击Java Basics->GC Roots

在新出来的GC Roots界面，点击线程选项，可以看到java.lang.Thread，也可以看到传说中的FinalizerThread。我们点击java.lang.Thread，找到主线程，里面可以看到我们的ArrayList和Date引用，是一个根结点

同样的方法打开新的hprof文件，这是把strings和date对象都置空后的快照，用上面的方法查看主线程的根结点集合，会发现已经没有了ArrayList和Date

根据线程下面的统计(21->19)，也可以证实对strings和date进行了GC

 

至此，使用mat溯源根结点就完成了

清除阶段：标记-清除算法

当堆中有效内存耗尽时，就会停止所有用户线程(Stop The World)，然后进行标记-清除

 

标记：收集器从根结点开始遍历，标记所有被引用的对象。一般是在对象的Header中记录为可达对象。关于对象的头部信息等内存布局，可以参见文章JVM学习之对象的实例化、内存布局与访问定位中对象的内存布局部分

清除：收集器对堆内存从头到尾进行线性遍历，如果发现某个对象在其Header中没有标记为可达对象，则将其清除。此处的清除不是真的置空，而是把需要清除的对象地址保存在空闲的地址列表里。下次要加载新的对象时，判断垃圾的位置空间是否够，如果够，就直接用新的对象覆盖原有的垃圾对象。

 

标记-清除算法过程举例如下图所示，绿色对象都是可达对象，在其Header中进行标记；在清除阶段，Header中没有记录可达标记的黑色对象，就都被回收了

 

 

缺点：

1）、效率不高，要遍历整个堆空间

2）、进行GC时，需要暂停整个应用程序，导致用户体验差

3）、会产生内存碎片，要维护一个空闲链表，以便实例化新对象时分配内存

关于空闲链表法分配内存，请参见文章JVM学习之对象的实例化、内存布局与访问定位中对象实例化的步骤部分

清除阶段：复制算法

将活着的内存空间分为两块，每次只使用其中的一块，在垃圾回收时将正在使用的内存中存活的对象复制到未被使用的内存块中，之后清除正在使用的内存块中的所有对象，交换两个内存块的角色，最后完成垃圾回收。

 

复制算法举例如下图所示，把内存分为A、B两块，两块内存大小相同。对A进行GC时，遍历根结点集合，把所有可达对象复制到未被使用的B区域中，不对对象添加任何标记，然后把A清空，完成GC。对B进行GC时，交换AB角色，如法炮制。

 

在现有JVM中，AB对应的是新生代里的幸存者0区和幸存者1区，所以幸存者区中的垃圾回收用的就是复制算法

 

优点：

1）、没有标记和清除过程，实现简单，运行高效

2）、复制过去后保证空间的连续性，为新对象分配内存时可采用指针碰撞的方式分配

关于指针碰撞法分配内存，请参见文章JVM学习之对象的实例化、内存布局与访问定位中对象实例化的步骤部分

 

缺点：

1）、需要两倍的内存空间

2）、对于G1这种分拆成大量region的GC，复制而不是移动，意味着GC要维护region之间对象的引用关系，不管是内存占用还是时间开销，都不算小

3）、如果系统中垃圾对象很少，则复制算法需要复制的存活对象数量很大，效果就不会很理想

 

不过对于新生代中的对象绝大多数都是朝生夕死，那么幸存者区使用复制算法就很合适。但老年代就不适合用这个算法了。

清除阶段：标记-压缩算法

标记：此阶段和标记-清除算法一样，从根结点开始标记所有被引用的对象

压缩：把所有存活对象压缩到内存的一端，按序排放，并清理边界外的所有空间

 

标记-压缩算法举例如下图所示

 

标记-压缩算法和标记-清除算法的区别是：前者是移动性算法，后者是非移动性算法。移动存活对象是一个优缺点并存的风险决策。

 

优点：

1）、消除了内存碎片，可以使用指针碰撞为新对象分配内存

2）、充分利用内存空间

 

缺点：

1）、效率不如复制算法

2）、移动对象时，如果对象被其他对象引用，则还需调整引用地址

3）、STW时间长

 

小结

三种经典GC算法对比如下表所示

经典GC算法的对比

	标记-清除	标记-压缩	复制
速率	中	最慢	最快
空间开销	少，但会堆积碎片	少，且不会堆积碎片	需要存活对象2倍大小的空间，但不堆积碎片
移动对象	否	是	是

 

复制算法的效率最高，但浪费了太多内存，用空间换时间

综合三个指标，标记-压缩算法相对更平滑，但效率很低，比复制算法多了一个标记阶段，比标记-清除算法多了一个整理内存阶段

 

没有最优的算法，只有最合适的算法，物尽其值

分代收集算法

分代收集算法是融合了上面三种算法的新算法，它基于对象的生命周期的不同采用不同的收集方式，以便提高回收效率。关于堆中的分代，可以参见文章JVM学习笔记之堆中年轻代与老年代部分

 

目前几乎所有GC都采用的是分代收集来进行GC的

 

对于年轻代，对象生命周期短，存活率低，回收频繁，而且空间比老年代小，所以这种情况采用复制算法最合适。HotSpot中的两个幸存者区可以缓解复制算法对空间的浪费

 

对于老年代，对象生命周期长，存活率高，回收频率比年轻代低，空间比较大，一般是由标记-清除和标记-压缩算法混合实现。标记阶段的时间开销和存活对象数量成正比，清除阶段的时间开销和所管理内存大小成正比，压缩阶段时间开销和存活对象大小成正比

 

以HotSpot中的CMS回收器为例，CMS是基于标记-清除算法实现的，回收效率高。对于碎片问题，CMS使用基于标记-整理的Serial Old回收器进行补偿；当内存回收效果不佳(内存碎片导致的Concurrent Mode Failure)时，将采用Serial Old执行Full GC达到对老年代内存的整理

 

增量收集算法、分区算法

这两种算法都是为了减少STW时间，提高用户体验

增量收集算法

让GC线程和用户线程交替执行，GC每次执行时，只收集一小片区域的内存空间。

增量收集算法通过对线程间冲突的妥善处理，允许GC线程以分阶段的方式完成标记、清理或复制工作

 

缺点：因为线程的切换和上下文转换的消耗，会造成GC的总体成本上升，造成系统吞吐量的下降

分区算法

将整个堆空间划分成连续的不同小区间(分代算法是按照对象生命周期长短，把堆区分成两个部分)，每个小区间独立使用，独立回收，可以存放伊甸园区、幸存区、老年代等区域的对象或者大对象

这种算法的好处是可以控制一次性回收多少个块

相关概念

System.gc()的理解

默认情况下，通过System.gc()或Runtime.getRuntime().gc()的调用可以显示触发Full GC

然而，System.gc()的调用附带一个免责声明，无法保证对垃圾收集器的立刻调用

所以，一般情况下，无需手动触发GC，否则就太麻烦了

 

如果一定要手动gc，可以同时调用System.gc()和System.runFinalization()两个方法

 

针对System.gc()方法和局部变量表的关系，请看以下代码，先使能输出详细的GC信息-XX:+PrintGCDetails

package jvm.gcDemos;


public class HandGC {


    public void localVarGc() {
        {
            byte[] bytes = new byte[10 * 1024 * 1024];
        }
        System.gc();
        // 此时bytes还占用着索引为1的局部变量表槽，所以不会被回收
    }


    public void localVarGc1() {
        {
            byte[] bytes = new byte[10 * 1024 * 1024];
        }
        int i = 0;
        // 此时bytes所占的索引为1的局部变量表槽，已经被i占据，所以bytes会被回收
        System.gc();
    }


    public static void main(String[] args) {
        HandGC test = new HandGC();
        test.localVarGc();
    }
}

调用方法localVarGc()时，输出的GC日志如下

[GC (System.gc()) [PSYoungGen: 15442K->10720K(75776K)] 15442K->11190K(249344K), 0.0201163 secs] [Times: user=0.00 sys=0.00, real=0.03 secs]
[Full GC (System.gc()) [PSYoungGen: 10720K->0K(75776K)] [ParOldGen: 470K->11095K(173568K)] 11190K->11095K(249344K), [Metaspace: 3233K->3233K(1056768K)], 0.0064126 secs] [Times: user=0.09 sys=0.00, real=0.01 secs]
...

System.gc()触发Full GC，Full GC会先触发新生代GC，所以第一行是PSYoungGen，PS表示Parallel System，用的是并发回收器

这次Full GC后，年轻代占用的空间直接清零，但老年代占用的空间却涨到了11095K，说明我们代码块里的10M的字节数组对象没有被回收掉，而是转到了老年代。

对于GC日志的解读，也可以参见文章JVM学习笔记之堆；关于GC日志参数的设置，可以参见本文的GC日志分析部分

查看localVarGC的局部变量表

会发现只有一个this指针，但局部变量表最大长度却是2

说明方法结束时，bytes占用的槽被清空，但调用System.gc()时方法没有结束，因此bytes还占着一个局部变量槽，因此它引用的对象不会被回收

关于局部变量槽与局部变量表，也可以参见文章JVM学习笔记上(概述-本地方法栈)

但调用localVarGc1()时，日志输出如下

[GC (System.gc()) [PSYoungGen: 15442K->968K(75776K)] 15442K->976K(249344K), 0.0007605 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
[Full GC (System.gc()) [PSYoungGen: 968K->0K(75776K)] [ParOldGen: 8K->829K(173568K)] 976K->829K(249344K), [Metaspace: 3200K->3200K(1056768K)], 0.0046999 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
...

年轻代照样被清空，老年代也只有829K，盛不下10M的bytes，因此可见bytes被回收了。原因是代码块执行完后，System.gc()执行前，我又声明了一个局部变量i，此时方法的局部变量表如下所示

并且局部变量表长度还是2

因此此时，调用System.gc()时，bytes占用的局部变量槽被i占用，因此引用消失，字节数组对象得以被回收

内存溢出与内存泄漏

内存溢出(OOM)

没有空闲内存，并且垃圾回收器回收后也不能提供更多内存

原因有二：

1）、JVM的堆内存设置不够，可通过-Xms、-Xmx来设置

2）、代码中创建了大量大对象，并且长时间不能被垃圾回收器回收

内存泄漏

对象不会再被程序使用，但GC又不能回收它们的情况

如上图所示，如果红色箭头表示的引用不消失，蓝色框内的对象就都不能被回收，而这些对象如果在程序中都不再使用的话，就发生了内存泄漏

 

举例：

1）、单例模式：单例的生命周期和应用程序一样长，所以在单例程序中，如果持有对外部对象的引用的话，这个外部对象是不能被回收的，就会导致内存泄漏

2）、一些提供close()的外部资源没有关闭

Stop The World

Stop The World(STW)指的是GC事件发生时，会造成用户线程的停顿，整个应用程序会被暂停，没有任何响应

这么做的原因，是因为GC时要首先找到所有根结点，如果分析过程时对象引用关系还在变化，那么分析结果的准确性将无法保证

 

GC完成后Stop The World就会结束，所有的GC都有这个事件，不可能被完全消除

垃圾回收的并行与并发

并行垃圾回收：多条收集线程并行工作，用户线程等待

并发垃圾回收：用户线程与收集线程同时进行，但依旧有STW

安全点与安全区域

安全点

能够停下来进行GC的程序位置，称之为安全点。

安全点太少，可能导致GC等待时间过长；安全点太多，导致GC频繁会影响程序性能。安全点的选择标准为能让程序长时间执行

常见的安全点有方法调用、循环跳转、异常跳转等

 

发生GC时，在安全点设置一个中断标志，各个线程运行到安全点时轮询这个标志，如果这个中断标志为真，则将自己进行中断挂起。这种方式称为主动中断方式。

安全区域

指的是在一段代码片段中，对象的引用关系不会发生变化，在这个区域中的任何位置开始GC都是安全的

实际执行

1）、当线程运行到安全区域的代码时，首先标识已经进入安全区域。如果这段时间内发生了GC，JVM会忽略标识为进入安全区域的线程

2）、当线程即将离开安全区域时，会检查JVM是否已经完成GC，如果完成了就继续运行；否则线程必须等待直到收到可以安全离开安全区域的信号为止

强引用

类似Object obj = new Object()这种引用关系，obj就是new Object()对象的强引用。

只要强引用关系还存在，GC就永远不会回收被引用的对象

 

特点：永远不回收

 

强引用是默认的引用类型，强引用的对象是可触及的，GC永远不会回收被强引用引用的对象，所以强引用是造成OOM的主要原因之一

软引用

系统要发生OOM之前，将会把只被软引用引用的对象放入回收范围之内进行二次回收。如果回收完之后还没有足够的内存，才抛出OOM。

 

特点：内存不足就回收

 

软引用通常用来实现内存敏感的缓存，比如高速缓存里就用到了软引用。被软引用关联的对象是软可触及的，当GC发生时，JVM会把软引用引用的对象放入软引用队列中，在内存不够、决定清除软可触及对象时，清空这个队列的元素及其引用的对象即可。

 

如果二次回收后内存还不够，那就只能报OOM了

 

举例

HandGC test = new HandGC();
SoftReference softReference = new SoftReference(test); // 建立对test引用的对象的软引用
test = null; // 断开强引用

// 以上三行代码等价于
// SoftReference softReference = new SoftReference(new HandGC());

test = softReference.get(); // 使用软引用对象
if (test!= null) {
    test.localVarGc();
}

弱引用

弱引用对象只能存活到下一次GC之前，GC时，不管内存空间是否足够，都会将其回收。

 

特点：发现就回收

 

只被弱引用引用的对象只能生存到下一次GC前，由于GC线程优先级很低，所以弱引用对象也可以存在很长时间。

软引用弱引用都很适合保存那些可有可无的缓存数据

 

一个安卓端使用弱引用优化Handler的例子如下所示

public class WeakHandler extends Handler {
    private WeakReference mWeakHandler;


    public WeakHandler(IHandler handler) {
        mWeakHandler = new WeakReference<>(handler);
    }


    @Override
    public void handleMessage(Message msg) {
        IHandler handler = mWeakHandler.get();
        if (handler != null) {
            handler.handleMessage(msg);
        }
    }
}

IHandler是接口，实现类通常就是Activity。Activity在覆写onCreate()方法时new一个WeakHandler，把自己传进去即可

当activity要被销毁时，WeakHandler里的mWeakHandler持有activity的弱引用，所以不影响activity对象的回收，因此避免了内存泄漏

虚引用

虚引用存在的唯一目的，就是在此对象被回收时，收到一个系统通知

 

如果一个对象仅持有虚引用，那它和没有引用基本是一样的，如果要使用虚引用的get()方法获取对象时，结果总是null

Object obj = new Object();
ReferenceQueue phantomQueue = new ReferenceQueue();
PhantomReference