JVM基础原理篇-带你深入拆解G1垃圾回收原理

一、一统天下的G1垃圾回收器概述

大白话：

        1.整个堆空间，新生代和老年代比例大概为2:8；

        2.正常情况下，新生代回收是高频的，混合回收是频率是适中的，完全回收则是基本不会发生、频率低代价高的，一旦发生距离系统崩溃不远矣。

大白话：

        1.Eden区不够了，触发YGC；

        2.新生代中的对象不断地晋升(满15次)老年代,当老年代达到阈值，则先触发混合回收，将新生代和部分老年代进行垃圾回收；

        3.如果回收后，老年代对象仍不够用，则会触发完全回收(FullGC);

        4.多次FullGC失败后，抛出OOM。

二、图解G1垃圾回收器YGC的基本原理与执行过程

大白话：

        1.方法区（元空间）所关联的类、对象，方法区里的东西一般是常驻内存的；

        2.正在执行的线程关联的类、对象，是不会被标记清除的；

        3.跨代引用，老年代引用了新生代对象，这些新生代对象也是不会被清除的；

这些对象都是可以作为GC root起点的。

大白话：

        我们通过对CMS的执行过程理解，首先是初始标记、并发标记、预处理、重新标记、并发清理、重置线程，而G1在标记为存活对象后，就立刻移动该对象到S区。

大白话：

        动态调整新生代区域region的数量 - 在G1里，在执行YGC的时候，新生代的数量是可以动态变化的，一般什么都不设置的情况下，Eden区占比例在5%~60%之间(调整的原因，是根据每次执行垃圾回收后，根据当前的情况判断增加region数量，每增加一个region数量，Eden区就会增加一个，如果没有必要，Eden数量太多，导致回收时间太长，这时JVM就会减少Eden区数量)。

大白话：

        当区块被回收后，就会变成自由分区(或者叫空白分区)，再有G1根据情况决定，这个区块下一步分变为Eden区还是别的区块。

大白话：

        在G1不断地YGC后，当某一次YGC判断老年代空间可能不太够用，则为下一次可能执行的混合回收做准备，提前开启并发标记，提高回收效率。

大白话：

        并行执行的任务，一般是重要的，且耗时短的。

大白话：

        1.释放分区 - 释放分区，类似我们的格式化硬盘，工作比较简单也比较快，涉及到一些全局状态表、全局集合的调整，所以采用串行的方式比较好。

三、【场景演示】通过GC日子理解YGC基本过程

大白话：

        young - YGC

        GC Workers - 8个工作线程

        Ext Root Scanning - GCRoots扫描

注意

        [Ext Root Scanning (ms):  0.4  0.6  0.2  0.2  0.2  0.1  0.2  0.1，从这里可以看出，不同的线程消耗的时间为什么会差异这么大，是因为不同的CPU的工作任务不同。

大白话： 

        total - G1堆总大小；

        used - 已使用堆大小；

        region size - 堆分区大小；

        28 young(28672k) - 年轻代分区有28个，总大小28672k;

        1 survivors(1024k) - S区1个，总大小1024k;

[Eden:9216.0K(9216.0K)垃圾回收之前占用空间大小 -> 0.0B垃圾回收之后占用空间大小(31.0M Eden区对占用空间大小 Survivors:0.0B -> 1024.0K Heap:9216.0K(128.0M) -> 848.1K(128.0M))]

再执行一次程序代码，发现

通过这两次对比，可以看出Eden区的堆空间大小被调整了，且Eden区的堆大小在5%~60%之间。

四、【原理精讲】停顿预测模型与垃圾区域选择原理

在启动参数中，增加一个 -XX:MaxGCPauseMillis=1 （最大停顿时间1，单位为1毫秒）

发现进行了多次GC，原因是每次GC都会尽量满足最大挺短时间，导出的后果就是每次垃圾会输的时间缩短了。

因为设置了最大停顿时间，导致GC时间内能处理的东西减少 ，从而JVM自动缩小了Eden区的堆大小。

大白话：

        最大停顿时间，设置过小，导致GC时间内能处理的东西减少 ，从而JVM自动缩小了Eden区的堆大小，设置过大，则导致在YGC的时候，S区放不下。

大白话：

        根据垃圾对象占对象的比例排序，如果本次能清理3个region，就1/2/3一起清理，如果只能清理2个就清理1/2，如果 只能清理1个region，就只清理1号region,选出来的region,放到CSet中。

五、【原理精讲】深入理解混合回收工作原理与执行过程

因为并发标记阶段耗时非常长，有些对象是死的，被标记成了活动，有些对象是活的被标记成了死的。

大白话：

        这里就是前面讲到的，怎么统计每个region的垃圾笔记、以及region回收排序。

大白话：

        1.混合回收前面为什么会有一次YGC呢，前面讲了混合回收的触发条件是，在YGC后，已分配的内存占总内存的45%，触发混合回收；

        2.并发标记，标记的什么呢，主要标记的是老年代的对象。

大白话：

        为什么存活对象数量大于 85%的region就不再回收，这是因为前面讲了，一边标记一边复制，最耗时的是复制移动对象，所以一旦超过85%的region,就没有放入CSet的中回收的必要。

大白话：

        也就说，要执行混合有两个条件，第一个，在YGC后，已分配的内存占总内存的45%，触发混合回收，第二个就是可回收的空间占总空间的比例大于5%，才会启动混合回收。如果低于5%，JVM认为启动混合回收的意义不大，所以不启动混合回收。

五、【场景演示】通过GC日志理解混合回收工作过程

将for循环改为500次：

通过检查GC日志，发现这一个YGC跟前面的YGC已经有了明显的区别，多做了一步初始标记操作，那么后面离它不远，就会有混合回收日志。

这里已经开始并发标记

开始混合回收

这一行表示，老年代空间已经不够使用，G1通过把新生代快速转为老年代，供老年代使用，出现这一行，表示离FullGC不远矣。

触发了2次FullGC

在FullGC后，又是YGC,说明暂时把系统救回来了

到最后，FullGC已经解决不了问题了，最终OOM了。

六、【原理精讲】深入理解FullGC工作原理与执行过程

大白话：

        FullGC执行时间非常长，大概2-3秒，如果执行一次仍然不够，会再次执行，第二次回收软引用，如果还不够用，对象仍然无法分配，系统基本上就要OOM了，所以FullGC是非常危险的，当出现FullGC,我们就应该进行检查，防止更大的风险发生。

大白话：

        标记活跃对象，是所有垃圾回收期的回收的前提。

七、【故障实战】大对象导致视频无法观看故障实战

大白话：

        经验证，G1采用的是第二种思路(即使用多个region)存放大对象。

        但是有个基本原则，大对象尽量不要放入老年代，因为老年代region是有数量限制的(默认2048个)，如果存放大量大对象，会把老年代占满，一旦占满应用会非常容易崩掉。

问题：

        现在的手机拍摄的视频一般都几百兆甚至几个G。

大白话：

        手动加大region大小，这个时候，大对象就不会被视为大对象，也就不会直接放入老年代region。

在前边的代码里，增加设置-XX:G1HeapRegionSize=8M，加入region大小。同时将代码中的byte1024改为1022，让数据的大小变小，可以看到执行的是YGC。

八、为什么sublist会导致系统OOM？

原因：

        subList所在的大对象，只要一直有在被引用，就一直不会被回收，而其本身占用的堆内存也一直不会释放，所以不推荐使用。