9、垃圾回收器

为什么分代GC算法要把堆分成年轻代和老年代？首先我们要知道堆内存中对象的特性：

系统中的大部分对象，都是创建出来之后很快就不再使用可以被回收，比如用户获取订单数据，订单数据返回给用户之后就可以释放了。
老年代中会存放长期存活的对象，比如Spring的大部分bean对象，在程序启动之后就不会被回收了。
在虚拟机的默认设置中，新生代大小要远小于老年代的大小。

分代GC算法将堆分成年轻代和老年代主要原因有：
1、可以通过调整年轻代和老年代的比例来适应不同类型的应用程序，提高内存的利用率和性能。
2、新生代和老年代使用不同的垃圾回收算法，新生代一般选择复制算法，老年代可以选择标记-清除和标记-整理算法，由程序员来选择灵活度较高。
3、分代的设计中允许只回收新生代（minor gc），如果能满足对象分配的要求就不需要对整个堆进行回收(full gc),STW时间就会减少。

垃圾回收器是垃圾回收算法的具体实现。
由于垃圾回收器分为年轻代和老年代，除了G1之外其他垃圾回收器必须成对组合进行使用。
具体的关系图如下：

在这里插入图片描述
年轻代-Serial垃圾回收器
Serial是是一种单线程串行回收年轻代的垃圾回收器。

回收年代和算法：
年轻代
复制算法
优点
单CPU处理器下吞吐量非常出色
缺点
多CPU下吞吐量不如其他垃圾回收器，堆如果偏大会让用户线程处于长时间的等待
适用场景
Java编写的客户端程序或者硬件配置有限的场景

老年代-SerialOld垃圾回收器
SerialOld是Serial垃圾回收器的老年代版本，采用单线程串行回收
-XX:+UseSerialGC 新生代、老年代都使用串行回收器。

在这里插入图片描述
回收年代和算法：
老年代
标记-整理算法
优点
单CPU处理器下吞吐量非常出色
缺点
多CPU下吞吐量不如其他垃圾回收器，堆如果偏大会让用户线程处于长时间的等待
适用场景
与Serial垃圾回收器搭配使用，或者在CMS特殊情况下使用

年轻代-ParNew垃圾回收器
ParNew垃圾回收器本质上是对Serial在多CPU下的优化，使用多线程进行垃圾回收
-XX:+UseParNewGC 新生代使用ParNew回收器，老年代使用串行回收器

在这里插入图片描述
回收年代和算法：
年轻代
复制算法
优点
多CPU处理器下停顿时间较短
缺点
吞吐量和停顿时间不如G1，所以在JDK9之后不建议使用
适用场景
JDK8及之前的版本中，与CMS老年代垃圾回收器搭配使用

老年代- CMS(Concurrent Mark Sweep)垃圾回收器
CMS垃圾回收器关注的是系统的暂停时间，允许用户线程和垃圾回收线程在某些步骤中同时执行，减少了用户线程的等待时间。
参数：XX:+UseConcMarkSweepGC

在这里插入图片描述
回收年代和算法：
老年代
标记清除算法
优点
系统由于垃圾回收出现的停顿时间较短，用户体验好
缺点
1、内存碎片问题
2、退化问题
3、浮动垃圾问题
适用场景
大型的互联网系统中用户请求数据量大、频率高的场景，比如订单接口、商品接口等

CMS执行步骤：
1.初始标记，用极短的时间标记出GC Roots能直接关联到的对象。
2.并发标记, 标记所有的对象，用户线程不需要暂停。
3.重新标记，由于并发标记阶段有些对象会发生了变化，存在错标、漏标等情况，需要重新标记。
4.并发清理，清理死亡的对象，用户线程不需要暂停。

缺点：
1、CMS使用了标记-清除算法，在垃圾收集结束之后会出现大量的内存碎片，CMS会在Full GC时进行碎片的整理。这样会导致用户线程暂停，可以使用-XX:CMSFullGCsBeforeCompaction=N 参数（默认0）调整N次Full GC之后再整理。
2.、无法处理在并发清理过程中产生的“浮动垃圾”，不能做到完全的垃圾回收。
3、如果老年代内存不足无法分配对象，CMS就会退化成Serial Old单线程回收老年代。

并发线程数：
在CMS中并发阶段运行时的线程数可以通过-XX:ConcGCThreads参数设置，默认值为0，由系统计算得出。
计算公式为(-XX:ParallelGCThreads定义的线程数 + 3) / 4， ParallelGCThreads是STW停顿之后的并行线程数
ParallelGCThreads是由处理器核数决定的：
1、当cpu核数小于8时，ParallelGCThreads = CPU核数
2、否则 ParallelGCThreads = 8 + (CPU核数 – 8 )5/8
我的电脑上逻辑处理器有12个，所以ParallelGCThreads = 8 + （12 - 8） 5/8 = 10，ConcGCThreads = (-XX:ParallelGCThreads定义的线程数 + 3) / 4 = （10 + 3） / 4 = 3
在这里插入图片描述
最终可以得到这张图：

并发标记和并发清理阶段，会使用3个线程并行处理。重新标记阶段会使用10个线程处理。
由于CPU的核心数有限，并发阶段会影响用户线程执行的性能。

年轻代-Parallel Scavenge垃圾回收器
Parallel Scavenge是JDK8默认的年轻代垃圾回收器，多线程并行回收，关注的是系统的吞吐量。具备自动调整堆内存大小的特点。
在这里插入图片描述
回收年代和算法：
年轻代
复制算法
优点
吞吐量高，而且手动可控。为了提高吞吐量，虚拟机会动态调整堆的参数
缺点
不能保证单次的停顿时间
适用场景
后台任务，不需要与用户交互，并且容易产生大量的对象。比如：大数据的处理，大文件导出

常用参数：
Parallel Scavenge允许手动设置最大暂停时间和吞吐量。Oracle官方建议在使用这个组合时，不要设置堆内存的最大值，垃圾回收器会根据最大暂停时间和吞吐量自动调整内存大小。

最大暂停时间，-XX:MaxGCPauseMillis=n 设置每次垃圾回收时的最大停顿毫秒数
吞吐量，-XX:GCTimeRatio=n 设置吞吐量为n（用户线程执行时间 = n/n + 1）
自动调整内存大小, -XX:+UseAdaptiveSizePolicy设置可以让垃圾回收器根据吞吐量和最大停顿的毫秒数自动调整内存大小

老年代-Parallel Old垃圾回收器
Parallel Old是为Parallel Scavenge收集器设计的老年代版本，利用多线程并发收集。
参数： -XX:+UseParallelGC 或
-XX:+UseParallelOldGC可以使用Parallel Scavenge + Parallel Old这种组合。
在这里插入图片描述
回收年代和算法：
老年代
标记-整理算法
优点
并发收集，在多核CPU下效率较高
缺点
暂停时间会比较长
适用场景
与Parallel Scavenge配套使用

G1垃圾回收器
JDK9之后默认的垃圾回收器是G1（Garbage First）垃圾回收器。Parallel Scavenge关注吞吐量，允许用户设置最大暂停时间，但是会减少年轻代可用空间的大小。CMS关注暂停时间，但是吞吐量方面会下降。
而G1设计目标就是将上述两种垃圾回收器的优点融合：
1.支持巨大的堆空间回收，并有较高的吞吐量。
2.支持多CPU并行垃圾回收。
3.允许用户设置最大暂停时间。
JDK9之后强烈建议使用G1垃圾回收器。

G1出现之前的垃圾回收器，年轻代和老年代一般是连续的，如下图：
在这里插入图片描述
G1的整个堆会被划分成多个大小相等的区域，称之为区Region，区域不要求是连续的。分为Eden、Survivor、Old区。Region的大小通过堆空间大小/2048计算得到，也可以通过参数-XX:G1HeapRegionSize=32m指定(其中32m指定region大小为32M)，Region size必须是2的指数幂，取值范围从1M到32M。
在这里插入图片描述
G1垃圾回收有两种方式：
1、年轻代回收（Young GC）
2、混合回收（Mixed GC）

年轻代回收
年轻代回收（Young GC），回收Eden区和Survivor区中不用的对象。会导致STW，G1中可以通过参数
-XX:MaxGCPauseMillis=n（默认200）设置每次垃圾回收时的最大暂停时间毫秒数，G1垃圾回收器会尽可能地保证暂停时间。
1、新创建的对象会存放在Eden区。当G1判断年轻代区不足（max默认60%），无法分配对象时需要回收时会执行Young GC。
在这里插入图片描述
2、标记出Eden和Survivor区域中的存活对象，
3、根据配置的最大暂停时间选择某些区域将存活对象复制到一个新的Survivor区中（年龄+1），清空这些区域。

G1在进行Young GC的过程中会去记录每次垃圾回收时每个Eden区和Survivor区的平均耗时，以作为下次回收时的参考依据。这样就可以根据配置的最大暂停时间计算出本次回收时最多能回收多少个Region区域了。
比如 -XX:MaxGCPauseMillis=n（默认200），每个Region回收耗时40ms，那么这次回收最多只能回收4个Region。
4、后续Young GC时与之前相同，只不过Survivor区中存活对象会被搬运到另一个Survivor区。
在这里插入图片描述

5、当某个存活对象的年龄到达阈值（默认15），将被放入老年代。

6、部分对象如果大小超过Region的一半，会直接放入老年代，这类老年代被称为Humongous区。比如堆内存是4G，每个Region是2M，只要一个大对象超过了1M就被放入Humongous区，如果对象过大会横跨多个Region。
在这里插入图片描述
7、多次回收之后，会出现很多Old老年代区，此时总堆占有率达到阈值时
（-XX:InitiatingHeapOccupancyPercent默认45%）会触发混合回收MixedGC。回收所有年轻代和部分老年代的对象以及大对象区。采用复制算法来完成。
在这里插入图片描述

混合回收
混合回收分为：初始标记（initial mark）、并发标记（concurrent mark）、最终标记（remark或者Finalize Marking）、并发清理（cleanup）
G1对老年代的清理会选择存活度最低的区域来进行回收，这样可以保证回收效率最高，这也是G1（Garbage first）名称的由来。
在这里插入图片描述
G1对老年代的清理会选择存活度最低的区域来进行回收，这样可以保证回收效率最高，这也是G1（Garbage first）名称的由来。最后清理阶段使用复制算法，不会产生内存碎片。

注意：如果清理过程中发现没有足够的空Region存放转移的对象，会出现Full GC。单线程执行标记-整理算法，此时会导致用户线程的暂停。所以尽量保证应该用的堆内存有一定多余的空间。
在这里插入图片描述
G1 – Garbage First 垃圾回收器
参数1： -XX:+UseG1GC 打开G1的开关，JDK9之后默认不需要打开
参数2：-XX:MaxGCPauseMillis=毫秒值最大暂停的时
回收年代和算法：
年轻代+老年代
复制算法
优点
对比较大的堆如超过6G的堆回收时，延迟可控
不会产生内存碎片
并发标记的SATB算法效率高
缺点
JDK8之前还不够成熟
适用场景
JDK8最新版本、JDK9之后建议默认使用

使用以下代码测试g1垃圾回收器，打印出每个阶段的时间:

package chapter04.gc;

import java.io.IOException;
import java.util.ArrayList;
import java.util.List;

/**
 * 垃圾回收器案例3
 */
//-XX:+UseG1GC   -Xmn8g -Xmx16g -XX:SurvivorRatio=8  -XX:+PrintGCDetails -verbose:gc 
public class GcDemo2 {

    public static void main(String[] args) throws IOException {
        int count = 0;
        List<Object> list = new ArrayList<>();
        while (true){
            //System.out.println(++count);
            if(count++ % 10240 == 0){
                list.clear();
            }
//            byte[] bytes = new byte[1024 * 1024 * 1];
            list.add(new byte[1024 * 1024 * 1 / 2]);
//            System.gc();
        }
    }
}

每个region大小为2m，一共有84个young区，26个幸存者区。
在这里插入图片描述
初始标记花了0.0478秒。

并发标记总共耗时10ms，不会产生STW。

总结
垃圾回收器的组合关系虽然很多，但是针对几个特定的版本，比较好的组合选择如下：
JDK8及之前：
ParNew + CMS（关注暂停时间）、Parallel Scavenge + Parallel Old (关注吞吐量)、 G1（JDK8之前不建议，较大堆并且关注暂停时间）