JVM垃圾收集算法及垃圾收集器深度刨析_随笔

JVM垃圾收集算法及垃圾收集器深度刨析

这篇文章我们在讲述垃圾收集算法以及垃圾收集器之前，我们首先需要对JVM的内存模型以及对象的生命周期有个大致的了解，所以我们从JVM的内存模型开始讲解，然后逐步延伸出今天的主题。

1. JVM 内存模型

在之前的文章中我们对运行时数据区描述了很多，其实重点存储数据的是堆和方法区(非堆)，所以内存的设计也着重从这两方面展开(注意这两块区域都是线程共享的)。

对于虚拟机栈，本地方法栈，程序计数器都是线程私有的。

可以这样理解，JVM运行时数据区是一种规范，而JVM内存模型是对该规范的实现。

接下来我们先来大致了解下 JVM 内存模型中有哪些区域。

一块是非堆区，一块是堆区
堆区分为两大块，一个是Old区，一个是Young区
Young区分为两大块，一个是Survivor区（S0+S1），一块是Eden区
S0和S1一样大，也可以叫From和To

2. 对象创建过程

一般情况下，新创建的对象都会被分配到Eden区，一些特殊的大的对象会直接分配到Old区。

我是一个普通的Java对象，我出生在Eden区，在Eden区我还看到和我长的很像的小兄弟，我们在Eden区中玩了挺长时间。有一天Eden区中的人实在是太多了，我就被迫去了Survivor区的“From”区，自从去了Survivor 区，我就开始漂了，有时候在Survivor的“From”区，有时候在Survivor的“To”区，居无定所。直到我18岁的时候。爸爸说我成人了，该去社会上闯闯了。于是我就去了老年代那边，在老年代里，人很多，并且年龄都挺大的。

从上图，我们应该可以大致了解一个对象是如何在各个区域中存活的，但是相信大家肯定会有一些问题，我们在这统一说明一下：

首先，如何理解图中的各种GC
Partial GC

Partial其实也就是部分的意思。那么翻译过来也就是回收部分GC堆的模式，他并不会回收我们整个堆。而我们的young GC以及我们的Old GC都属于这种模式
young GC

只回收young区
old GC

只回收Old区
full GC

实际上就是对于整体的回收
Young区中为什么需要Survivor区？只有Eden不行吗？

如果没有Survivor，Eden区每进行一次Minor GC，存活的对象就会被送到老年代。

这样一来，老年代很快被填满，触发Major GC（因为Major GC一般伴随着Minor GC，也可以看做触发了

Full GC）。

老年代的内存空间远大于新生代，进行一次Full GC消耗的时间比Minor GC长得多。

执行时间长有什么坏处？频发的Full GC消耗的时间很长，会影响大型程序的执行和响应速度。

可能你会说，那就对老年代的空间进行增加或者较少咯。

假如增加老年代空间，更多存活对象才能填满老年代。虽然降低Full GC频率，但是随着老年代空间加大，一旦发生Full GC，执行所需要的时间会变得更长。

假如减少老年代空间，虽然Full GC所需时间减少，但是老年代很快被存活对象填满，Full GC频率增加。

所以Survivor的存在意义，就是减少被送到老年代的对象，进而减少Full GC的发生，Survivor的预筛选保

证，只有经历16次Minor GC还能在新生代中存活的对象，才会被送到老年代。
为什么需要两个Survivor区？

最大的好处就是解决了碎片化。也就是说为什么一个Survivor区不行？第一部分中，我们知道了必须设置 Survivor区。假设现在只有一个Survivor区，我们来模拟一下流程:

刚刚新建的对象在Eden中，一旦Eden满了，触发一次Minor GC，Eden中的存活对象就会被移动到Survivor区。这样继续循环下去，下一次Eden满了的时候，问题来了，此时进行Minor GC，Eden和Survivor各有一些存活对象，如果此时把Eden区的存活对象硬放到Survivor区，很明显这两部分对象所占有的内存是不连续的，也就导致了内存碎片化。

所以为了解决这个问题，我们使用两个Survivor区域。永远有一个Survivor space是空的，另一个非空的Survivor space无碎片。
新生代中Eden：S1：S2为什么是8：1：1？

新生代中的可用内存：复制算法用来担保的内存为9:1 ;

可用内存中Eden:S1区为8:1 ;

即新生代中Eden:S1:S2 = 8:1:1 ;

现代的商业虚拟机都采用这种收集算法来回收新生代，IBM公司的专门研究表明，新生代中的对象大概98%是“朝生夕死”的。
堆内存中都是线程共享的区域吗？

JVM默认为每个线程在Eden上开辟一个buffer区域，用来加速对象的分配，称之为TLAB，全称:Thread Local Allocation Buffer。

对象优先会在TLAB上分配，但是TLAB空间通常会比较小，如果对象比较大，那么还是在共享区域分配。

3. 对象的生命周期

了解对象的创建过程之后，我们来看看对象的生命周期包括那几个阶段：

创建阶段( Created )
应用阶段( In Use )
不可见阶段( Invisible )
不可达阶段( Unreachable )
收集阶段( Collected )
终结阶段( Finalized )
对象空间重分配阶段( De-allocated )

在聊这个之前，我觉得我们应该先聊一聊对象的引用，一般来说，我们的引用有四种。

3.1 引用

强引用

在 Java 中最常见的就是强引用，也是我们在开发过程中经常会使用到的引用。把一个对象赋给一个引用变量，这个引用变量就是一个强引用。当一个对象被强引用变量引用时，它处于可达状态，它是不可能被垃圾回收机制回收的，即使该对象以后永远都不会被用到 JVM 也不会回收。因此强引用是造成 Java内存泄漏的主要原因之一。

软引用

软引用需要用 SoftReference 类来实现，对于只有软引用的对象来说，当系统内存足够时它不会被回收，当系统内存空间不足时它会被回收。软引用通常用在对内存敏感的程序中。起到类似与缓存的作用。

public class SoftReferenceDemo {

    public static void main(String[] args) {
        //一堆业务代码
        Worker a = new Worker();
        //业务代码使用到了Worker实例 该类可以自行定义

        // 使用完了a，将它设置为soft 引用类型，并且释放强引用；
        SoftReference sr = new SoftReference(a);
        a = null;

        // 下次使用时
        if (sr != null) {
            a = (Worker) sr.get();
        } else {
            // GC由于内存资源不足，可能系统已回收了a的软引用，
            // 因此需要重新装载。
            a = new Worker();
            sr = new SoftReference(a);
        }
    }
}

弱引用

弱引用需要用 WeakReference 类来实现，它比软引用的生存期更短，对于只有弱引用的对象来说，只要垃圾回收机制一运行，不管 JVM 的内存空间是否足够，总会回收该对象占用的内存。

public class WeakReferenceDemo {
    public static void main(String[] args) throws InterruptedException {
        //100M的缓存数据
        byte[] cacheData = new byte[100 * 1024 * 1024];
        //将缓存数据用弱引用持有
        WeakReference cacheRef = new WeakReference<>(cacheData);
        System.out.println("第一次GC前" + cacheData);
        System.out.println("第一次GC前" + cacheRef.get());
        //进行一次GC后查看对象的回收情况
        System.gc();
        //等待GC
        Thread.sleep(500);
        System.out.println("第一次GC后" + cacheData);
        System.out.println("第一次GC后" + cacheRef.get());

        //将缓存数据的强引用去除
        cacheData = null;
        System.gc();
        //等待GC
        Thread.sleep(500);
        System.out.println("第二次GC后" + cacheData);
        System.out.println("第二次GC后" + cacheRef.get());
    }
}

这个例子演示的是我们创建一个实例，然后将数据给弱引用持有，第一次GC的时候，由于强引用还在，所以并没有回收，当我们将强引用去除后在进行GC，可以发现数据被回收了。

虚引用

虚引用需要 PhantomReference 类来实现，它不能单独使用，必须和引用队列联合使用。虚引用的主要作用是跟踪对象被垃圾回收的状态。

上述四种引用，实际上后两种应用我们很少使用到。

了解引用之后，我们来聊一下对应生命周期的各个阶段。

3.2 创建阶段

其实我们在探讨类加载的时候就已经探讨了一部分对象创建的情况。

为对象分配存储空间
开始构造对象
从超类到子类对static成员进行初始化
超类成员变量按顺序初始化，递归调用超类的构造方法
子类成员变量按顺序初始化，子类构造方法调用
一旦对象被创建，并被分派给某些变量赋值，这个对象的状态就切换到了应用阶段

3.3 应用阶段( In Use )

对象至少被一个强引用持有着。

3.4 不可见阶段( Invisible )

当一个对象处于不可见阶段时，说明程序本身不再持有该对象的任何强引用，虽然该这些引用仍然是存在着的。

简单说就是程序的执行已经超出了该对象的作用域了。

3.5 不可达阶段( Unreachable )

对象处于不可达阶段是指该对象不再被任何强引用所持有。

与“不可见阶段”相比，“不可见阶段”是指程序不再持有该对象的任何强引用，这种情况下，该对象仍可能被 JVM 等系统下的某些已装载的静态变量或线程或 JNI 等强引用持有着，这些特殊的强引用被称为”GC root ”。存在着这些 GC root 会导致对象的内存泄露情况，无法被回收。

3.6 收集阶段( Collected )

当垃圾回收器发现该对象已经处于“不可达阶段”并且垃圾回收器已经对该对象的内存空间重新分配做好准备时，则对象进入了“收集阶段”。如果该对象已经重写了 finalize() 方法，则会去执行该方法的终端 *** 作。具体的 *** 作可以参考下图。

这里要特别说明一下：不要重载finazlie()方法！原因有两点：

会影响JVM的对象分配与回收速度

在分配该对象时，JVM需要在垃圾回收器上注册该对象，以便在回收时能够执行该重载方法；在该方法的执行时需要消耗CPU时间且在执行完该方法后才会重新执行回收 *** 作，即至少需要垃圾回收器对该对象执行两次GC。
可能造成该对象的再次“复活”

在finalize()方法中，如果有其它的强引用再次持有该对象，则会导致对象的状态由“收集阶段”又重新变为“应用阶段”。这个已经破坏了Java对象的生命周期进程，且“复活”的对象不利用后续的代码管理。

3.7 终结阶段

当对象执行完finalize()方法后仍然处于不可达状态时，则该对象进入终结阶段。在该阶段是等待垃圾回收器对该对象空间进行回收。

3.8 对象空间重新分配阶段

垃圾回收器对该对象的所占用的内存空间进行回收或者再分配了，则该对象彻底消失了，称之为“对象空间重新分配阶段”。

4. 什么时候会进行垃圾回收

GC是由JVM自动完成的，根据JVM系统环境而定，所以时机是不确定的。

当然，我们可以手动进行垃圾回收，比如调用System.gc()方法通知JVM进行一次垃圾回收，但是具体什么时刻运行也无法控制。也就是说System.gc()只是通知要回收，什么时候回收由JVM决定。但是不建议手动调用该方法，因为GC消耗的资源比较大。

以下情况会发生垃圾回收：

（1）当Eden区或者S区不够用了

（2）老年代空间不够用了

（3）方法区空间不够用了

（4）System.gc()

5. 垃圾收集算法

已经能够确定一个对象为垃圾之后，接下来要考虑的就是回收，怎么回收呢？得要有对应的算法，下面介绍常见的垃圾回收算法。

5.1 标记-清除 (Mark-Sweep)

标记

找出内存中需要回收的对象，并且把它们标记出来。

此时堆中所有的对象都会被扫描一遍，从而才能确定需要回收的对象，比较耗时。
清除

清除掉被标记需要回收的对象，释放出对应的内存空间。

这种算法具有一些缺点，从上面两张图中，我相信大家一定也看出了这种算法一个很明显的缺点：内存碎片。

标记和清除两个过程都比较耗时，效率不高。
该算法会产生大量不连续的内存碎片，空间碎片太多可能会导致以后在程序运行过程中需要分配较大对象时，无法找到足够的连续内存而不得不提前触发另一次垃圾收集动作。

5.2 标记-复制 (Mark-Copying)

为了解决内存碎片的问题，我们可以将内存划分为两块相等的区域，每次只使用其中一块，如下图所示：

当其中一块内存使用完了，就将还存活的对象复制到另外一块上面，然后把已经使用过的内存空间一次清除掉。

这种算法的缺点相信大家一定也看出来了，没错，这种算法就是典型的空间换时间的算法，他导致我们的空间利用率太低了。

5.3 标记-整理 (Mark-Compact)

复制收集算法在对象存活率较高时就要进行较多的复制 *** 作，效率将会变低。更关键的是，如果不想浪费50%的空间，就需要有额外的空间进行分配担保，以应对被使用的内存中所有对象都有100%存活的极端情况，所以老年代一般不能直接选用这种算法。

标记过程仍然与"标记-清除"算法一样，但是后续步骤不是直接对可回收对象进行清理，而是让所有存活的对象都向一端移动，然后直接清理掉端边界以外的内存。

让所有存活的对象都向一端移动，清理掉边界意外的内存。

6. 分代收集算法

既然我们上面介绍了3中垃圾收集算法，那么在堆内存中到底用哪一个呢？

Young区：复制算法(对象在被分配之后，生命周期比较短，Young区复制效率比较高)

Old区：标记清除或标记整理(Old区对象存活时间比较长，复制来复制去没必要，不如做个标记再清理)

7. 垃圾收集器

在了解垃圾收集器前，我们可以先初步了解一下JVM参数：

https://blog.csdn.net/qq_41432730/article/details/122279754

如果说收集算法是内存回收的方法论，那么垃圾收集器就是内存回收的具体实现。

7.1 Serial

Serial收集器是最基本、发展历史最悠久的收集器，曾经（在JDK1.3.1之前）是虚拟机新生代收集的唯一选择。

它是一种单线程收集器，不仅仅意味着它只会使用一个CPU或者一条收集线程去完成垃圾收集工作，更重要的是其在进行垃圾收集的时候需要暂停其他线程。也就是我们常说的STOP THE WROLD。

优点：简单高效，拥有很高的单线程收集效率

缺点：收集过程需要暂停所有线程

算法：复制算法

适用范围：新生代

应用：Client模式下的默认新生代收集器

7.2 Serial Old

Serial Old收集器是Serial收集器的老年代版本，也是一个单线程收集器，不同的是采用"标记-整理算法"，运行过程和Serial收集器一样。

7.3 ParNew

我们可以把这个收集器理解为Serial收集器的多线程版本。

优点：在多CPU时，比Serial效率高。

缺点：收集过程暂停所有应用程序线程，单CPU时比Serial效率差。

算法：复制算法

适用范围：新生代

应用：运行在Server模式下的虚拟机中首选的新生代收集器

7.4 Parallel Scavenge

Parallel Scavenge收集器是一个新生代收集器，它也是使用复制算法的收集器，又是并行的多线程收集器，看上去和ParNew一样，但是Parallel Scanvenge更关注系统的吞吐量。

吞吐量=运行用户代码的时间/(运行用户代码的时间+垃圾收集时间)

比如虚拟机总共运行了100分钟，垃圾收集时间用了1分钟，吞吐量=(100-1)/100=99%。

若吞吐量越大，意味着垃圾收集的时间越短，则用户代码可以充分利用CPU资源，尽快完成程序的运算任务。

我们可以通过相关参数进行设置：

-XX:MaxGCPauseMillis 控制最大的垃圾收集停顿时间，

-XX:GCTimeRatio 直接设置吞吐量的大小。

7.5 Parallel Old

Parallel Old收集器是Parallel Scavenge收集器的老年代版本，使用多线程和标记-整理算法进行垃圾回收，也是更加关注系统的吞吐量。

7.6 CMS

官网：

https://docs.oracle.com/javase/8/docs/technotes/guides/vm/gctuning/cms.html#concurrent_mark_sweep_cms_collector

CMS(Concurrent Mark Sweep)收集器是一种以获取最短回收停顿时间为目标的收集器。

采用的是"标记-清除算法"，整个过程分为4步：

初始标记 CMS initial mark

标记GC Roots直接关联对象，不用Tracing，速度很快
并发标记 CMS concurrent mark

进行GC Roots Tracing
重新标记 CMS remark

修改并发标记因用户程序变动的内容
并发清除 CMS concurrent sweep

清除不可达对象回收空间，同时有新垃圾产生，留着下次清理称为浮动垃圾

由于整个过程中，并发标记和并发清除，收集器线程可以与用户线程一起工作，所以总体上来说，CMS收集器的内存回收过程是与用户线程一起并发地执行的。

优点：并发收集、低停顿

缺点：产生大量空间碎片、并发阶段会降低吞吐量，还会并发失败

需要注意的是，实际上CMS分为两个模式：

backgroud模式为正常模式执行上述的CMS GC流程

forefroud模式为Full GC模式

同时CMS并发GC不是“full GC”。HotSpot VM里对concurrent collection和full collection有明确的区分。所有带有“FullCollection”字样的VM参数都是跟真正的full GC相关，而跟CMS并发GC无关的。

如果想要深入研究，可以参考hotspot源码部分。

JVM垃圾收集算法及垃圾收集器深度刨析

发表评论

评论列表（0条）