首先先来回答一下上篇文章中最后留给大家的问题：
为什么分代GC算法要把堆分为年轻代和老年代？
- 系统中的大部分对象，都是创建出来之后很快就不再使用可以被回收，比如用户获取订单数据，订单数据返回给用户之后就可以释放了。
- 老年代中会存放长期存活的对象，比如Spring的大部分bean对象，在程序启动之后就不会被回收了。
- 在虚拟机中的默认设置中，新生代大小要远远小于老年代的大小。
所以分代GC算法将堆分成年轻代和老年代的比例来适应不同类型的应用程序，提高内存的利用率和性能
1、可以通过调整年轻代和老年代的比例来适应不同类型的应用程序，提高内存的利用率和性能。
2、新生代和老年代使用不同的垃圾回收算法，新生代一般选择复制算法，老年代可以选择标记-清除和标记-整理算法，由程序员来选择灵活度较高。
3、分代的设计中允许只回收新生代(Minor GC)，如果能满足对象分配的要求就不需要对整个堆进行回收(Full Gc),STW时间就会减少
垃圾回收器的组合关系：
垃圾回收器是垃圾回收算法的具体实现。
由于垃圾回收器分为年轻代和老年代，除了G1之外其他垃圾回收器必须成对组合进行使用。
一、垃圾回收器的种类
年轻代—Serial垃圾回收器
Serial是一种单线程串行回收年轻代的垃圾回收器。
回收年代和算法：年轻代、复制算法。
优点：单CPU处理器下吞吐量非常出色。
缺点：多CPU下吞吐量不如其他垃圾回收器，堆如果偏大会让用户线程处于长时间的等待
适用场景：java编写的客户端程序或者硬件配置有限的场景
老年代—Serial垃圾回收器
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次Ful GC之后再整理。
2.、无法处理在并发清理过程中产生的“浮动垃圾”，不能做到完全的垃圾回收。
3、如果老年代内存不足无法分配对象，CMS就会退化成Serial Old单线程回收老年代,
年轻代—Parallel Scavenge垃圾回收器
Parallel Scavenge是JDK8默认的年轻代垃圾回收器，多线程并行回收，关注的是系统的吞吐量。具备自动调整堆内存大小的特点。
回收年代和算法：年轻代、复制算法。
优点：吞吐量高，而且手动可控。为了提高吞吐量，虚拟机会动态调整堆的参数
缺点：不能保证单次的停顿时间
适用场景：后台任务，不需要与用户交互，并且容易产生大量的对象。比如：大数据的处理，大文件的导出
老年代—Parallel Old垃圾回收器
Parallel Old是为了Parallel Scavenge收集器设计的老年代版本，利用多线程并发收集。
参数：-XX:+UseParallelGC或-XX:+UseParallelOldGC，可以使用Parallel Scavenge+Parallel Old这种组合。
回收年代和算法：老年代、标记-整理算法。
优点：并发收集，在多核CPU下效率较高
缺点：暂停时间会比较长
适用场景：与Parallel Scavenge配套使用
Parallel Scavenge垃圾回收器
Parallel Scavenge允许手动设置最大暂停时间和吞吐量。
Oracle官方建议在使用这个组合时，不要设置堆内存的最大值，垃圾回收器会根据最大暂停时间和吞吐量自动调整内存大小。
最大暂停时间：-XX:MaxGCPauseMillis=n，设置每次垃圾回收时的最大停顿毫秒数
吞吐量：-XX:GCTimeRatio=n，设置吞吐量为n，(用户线程执行时=n/n+1)
自动调整内存大小：-XX:+UseAdaptiveSizePolicy设置可以让垃圾回收器根据吞吐量和最大停顿的毫秒数自动调整内存大小
G1垃圾回收器
JDK9之后默认的垃圾回收器是G1(Garbage First)垃圾回收器。
Parallel Scavenge关注吞吐量，允许用户设置最大暂停时间，但是会减少年轻代可用空间的大小。
CMS关注暂停时间，但是吞吐量方面会下降，
而G1设计目标就是将上述两种垃圾回收器的优点融合:
- 支持巨大的堆空间回收，并有较高的吞吐量。
- 支持多CPU并行垃圾回收。
- 允许用户设置最大暂停时间。
JDK9之后强烈建议使用G1垃圾回收器
G1垃圾回收器-内存结构
G1出现之前的垃圾回收器，内存结构一般是连续的，如图
G1的整个堆会被划分成多个大小相等的区域，称之为区Region，区域不要求是连续的。分为Eden、Survivor、Old区。Reqion的大小通过堆空间大小/2048计算得到，也可以通过参数-XX:G1HeapRegionSize=32m指定(其中32m指定region大小为32M)，Region size必须是2的指数幕，取值范围从1M到32M。
G1垃圾回收有两种方式：
1、年轻代回收(Young GC)
回收Eden区和Survivor区中不用的对象。会导致STW，G1中可以通过参数-XX:MaxGCPauseMiis=n(默认200)设置每次垃圾回收时的最大暂停时间毫秒数，G1垃圾回收器会尽可能地保证暂停时间。
执行流程：
①新创建的对象会存放在Eden区，当G1判断年轻代区不足(max默认60%)，无法分配对象时需要回收时会执行Young GC。
②标记出Eden和Survivor区域中的存活对象。
③根据配置的最大暂停时间选择某些区域将存活对象复制到一个新的Survivor区中(年龄+1)，清空这些区域。
G1在进行Young GC的过程中会去记录每次垃圾回收时每个Eden区和Survivor区的平均耗时，以作为下次回收时的参考依据。这样就可以根据配置的最大暂停时间计算出本次回收时最多能回收多少个Region区域了。比如 -XX:MaxGCPauseMilis=n(默认200)，每个Region回收耗时40ms，那么这次回收最多只能回收4个Region。
④后续Young GC时与之前相同，只不过Survivor区中存活对象会被搬运到另一个Survivor区。
⑤当某个存活对象的年龄到达阈值(默认15)，将被放入老年代。
⑥部分对象如果大小超过Region的一半，会直接放入老年代，这类老年代被称为Humongous区。比如堆内存是4G,每个Region是2M，只要一个大对象超过了1M就被放入Humongous区，如果对象过大会横跨多个Region。
2、混合回收(Mixed GC)
⑦多次回收之后，会出现很多Old老年代区，此时总堆占有率达到阈值时
(-XX:InitiatingHeap0ccupancyPercent默认45%)会触发混合回收MixedGc。回收所有年轻代和
部分老年代的对象以及大对象区。采用复制算法来完成。
- 混合回收分为:初始标记(initial mark)、并发标记(concurrent mark)、最终标记(remark或者FinalizeMarking)、并发清理(cleanup)
- G1对老年代的清理会选择存活度最低的区域来进行回收，这样可以保证回收效率最高，这也是G1(Garbagefirst)名称的由来
最后清理阶段使用复制算法，不会产生内存碎片。左边是回收前，右边是回收后
注意:如果清理过程中发现没有足够的空Region存放转移的对象，会出现FulGC。单线程执行标记-整理算法，此时会导致用户线程的暂停。所以尽量保证应该用的堆内存有一定多余的空间。
G1—Garbage First 垃圾回收器
参数1：-XX:+UseG1GC 打开G1的开关，JDK9之后默认不需要打开。
参数2：-XX:MaxGCPauseMillis=毫秒值最大暂停的时间
回收年代和算法：年轻代+老年代、复制算法。
优点：对比较大的堆如超过6G的堆回收时，延迟可控，不会产生内存碎片，并发标记的SATB算法效率高
缺点：JDK8之前还不够成熟
适用场景：JDK8最新版本、JDK9之后建议默认使用
总结：
垃圾回收器的组合关系虽然很多，但是针对几个特定的版本，比较好的组合选择如下:
JDK8及之前:
ParNew +CMS(关注暂停时间)、Parallel Scavenge + Parallel Old (关注吞吐量)、 G1(JDK8之前不建议，较大堆并且关注暂停时间)
JDK9之后:
G1(默认)
从JDK9之后，由于G1日趋成熟，JDK默认的垃圾回收器已经修改为G1，所以强烈建议在生产环境上使用G1。
