jvm基础篇之垃圾回收[3](垃圾回收器)

分代GC代取划分原因

为什么分代GC算法要把堆分成年轻代和老年代？

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

分代GC算法将堆分成年轻代和老年代主要原因有：

可以通过调整年轻代和老年代的比例来适应不同类型的应用程序，提高内存的利用率和性能。
新生代和老年代使用不同的垃圾回收算法，新生代一般选择复制算法，老年代可以选择标记-清除和标记-整理算法，由程序员来选择灵活度较高。
分代的设计中允许只回收新生代（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垃圾回收器

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

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

CMS执行步骤：

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

CMS垃圾回收器存在的问题（缺点）

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

CMS垃圾回收器存在的问题 – 线程资源争抢问题

在CMS中并发阶段运行时的线程数可以通过-XX:ConcGCThreads参数设置，默认值为0，由系统计算得出
计算公式为(-XX:ParallelGCThreads定义的线程数 + 3) / 4， ParallelGCThreads是STW停顿之后的并行线程数
ParallelGCThreads是由处理器核数决定
1. 当cpu核数小于8时， $P a r a ll e lGCT h re a d s = CP U 核数$
2. 否则 $ParallelGCThreads = 8 + (CPU核数 – 8 )*5/8 $
由于CPU的核心数有限，就会影响用户线程执行的性能

年轻代-Parallel Scavenge垃圾回收器

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

老年代-Parallel Old垃圾回收器

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

Parallel Scavenge允许手动设置最大暂停时间和吞吐量
Oracle官方建议在使用这个组合时，不要设置堆内存的最大值，垃圾回收器会根据最大暂停时间和吞吐量自动调整内存大小。
最大暂停时间：-XX:MaxGCPauseMillis=n设置每次垃圾回收时的最大停顿毫秒数
吞吐量：-XX:GCTimeRatio=n设置吞吐量为n（用户线程执行时间 = n/n + 1）
自动调整内存大小：-XX:+UseAdaptiveSizePolicy设置可以让垃圾回收器根据吞吐量和最大停顿的毫秒数自动调整内存大小

G1垃圾回收器

JDK9之后默认的垃圾回收器是G1（Garbage First）垃圾回收器。
G1设计目标就是将Parallel Scavenge关注吞吐量，允许用户设置最大暂停时间垃圾回收器的优点和CMS关注暂停时间垃圾回收器的优点融合：
1. 支持巨大的堆空间回收，并有较高的吞吐量。
2. 支持多CPU并行垃圾回收。
3. 允许用户设置最大暂停时间。
JDK9之后强烈建议使用G1垃圾回收器

G1内存结构

G1的整个堆会被划分成多个大小相等的区域，称之为区Region，区域不要求是连续的。Region分为Eden、Survivor、Old区。
Region的大小通过 $堆空间大小 /2048$ 计算得到，也可以通过参数-XX:G1HeapRegionSize=32m指定(其中32m指定region大小为32M)，Region size必须是2的指数幂，取值范围从1M到32M。

G1回收方式

G1垃圾回收有两种方式：年轻代回收和混合回收

年轻代回收

年轻代回收（Young GC），回收Eden区和Survivor区中不用的对象,会导致STW，G1中可以通过参数-XX:MaxGCPauseMillis=n（默认200） 设置每次垃圾回收时的最大暂停时间毫秒数，G1垃圾回收器会尽可能地保证暂停时间

混合回收

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

FULL GC

如果清理过程中发现没有足够的空Region存放转移的对象，会出现Full GC。单线程执行标记-整理算法，此时会导致用户线程的暂停。所以尽量保证应该用的堆内存有一定多余的空间.

G1执行流程

新创建的对象会存放在Eden区。当G1判断年轻代区不足（max默认60%），无法分配对象时需要回收时会执行Young GC。
标记出Eden和Survivor区域中的存活对象
根据配置的最大暂停时间选择某些区域将存活对象复制到一个新的Survivor区中（年龄+1），清空这些区域
后续Young GC时与之前相同，只不过Survivor区中存活对象会被搬运到另一个Survivor区
当某个存活对象的年龄到达阈值（默认15），将被放入老年代
部分对象如果大小超过Region的一半，会直接放入老年代，这类老年代被称为Humongous区。比如堆内存是4G，每个Region是2M，只要一个大对象超过了1M就被放入Humongous区，如果对象过大会横跨多个Region
多次回收之后，会出现很多Old老年代区，此时总堆占有率达到阈值时-XX:InitiatingHeapOccupancyPercent默认45%会触发混合回收MixedGC。回收所有年轻代和部分老年代的对象以及大对象区。采用复制算法来完成。

G1在进行Young GC的过程中会记录每次垃圾回收时每个Eden区和Survivor区的平均耗时，作为下次回收时的参考依据。根据配置的最大暂停时间计算出本次回收时最多能回收多少个Region区域
比如-XX:MaxGCPauseMillis=n（默认200），每个Region回收耗时40ms，那么这次回收最多只能回收4个Region