并发回收器：CMS、G1
两个收集器间有连线，表明他们可以搭配使用：Serial/Serial old、Serial/CMS、ParNew/Serial Old、ParNew/CMS、Parallel Scavenge/Serial Old、Parallel Scavenge/Parallel Old、G1；
其中Serial Old作为CMS出现失败“Concurrent Mode Failure”的后备预案
（红色虚线）由于维护和兼容性测试的成本，在JDK 8时将Serial+CMS、ParNew+Serial old这两个组合声明为废弃（JEP173），并在JDK9中完全取消了这些组合的支持（JEP214），即：移除。
（绿色虚线）JDK14中：弃用Parallel Scavenge和Serialold GC组合（JEP366）
（青色虚线）JDK14中：删除CMS垃圾回收器（JEP363）
ps: jdk8默认的是 Parallel Scavenge/Parallel Old
-XX:+PrintcommandLineFlags：查看命令行相关参数（包含使用的垃圾收集器）
为什么要有很多收集器，一个不够吗？ 因为Java的使用场景很多，移动端，服务器等。所以就需要针对不同的场景，提供不同的垃圾收集器，提高垃圾收集的性能。
虽然我们会对各个收集器进行比较，但并非为了挑选一个最好的收集器出来。没有一种放之四海皆准、任何场景下都适用的完美收集器存在，更加没有万能的收集器。所以我们选择的只是对具体应用最合适的收集器。
垃圾回收器总结7款不同的垃圾收集器。每一款的垃圾收集器都有不同的特点，在具体使用的时候，需要根据具体的情况选用不同的垃圾收集器。
GC发展阶段：Serial => Parallel（并行）=> CMS（并发）=> G1 => ZGC
怎么选择垃圾回收器
Java垃圾收集器的配置对于JVM优化来说是一个很重要的选择，选择合适的垃圾收集器可以让JVM的性能有一个很大的提升。怎么选择垃圾收集器？
优先调整堆的大小让JVM自适应完成。
如果内存小于100M，使用串行收集器
如果是单核、单机程序，并且没有停顿时间的要求，串行收集器
如果是多CPU、需要高吞吐量、允许停顿时间超过1秒，选择并行或者JVM自己选择
如果是多CPU、追求低停顿时间，需快速响应（比如延迟不能超过1秒，如互联网应用），使用并发收集器
官方推荐G1，性能高。现在互联网的项目，基本都是使用G1。
最后需要明确一个观点：
没有最好的收集器，更没有万能的收集器
调优永远是针对特定场景、特定需求，不存在一劳永逸的收集器
常见垃圾回收器组合参数设定：(1.8)-XX:+UseSerialGC = Serial New (DefNew) + Serial Old
小型程序。默认情况下不会是这种选项，HotSpot会根据计算及配置和JDK版本自动选择收集器
-XX:+UseParNewGC = ParNew + SerialOld
这个组合已经很少用（在某些版本中已经废弃）
https://stackoverflow.com/questions/34962257/why-remove-support-for-parnewserialold-anddefnewcms-in-the-future
-XX:+UseConc(urrent)MarkSweepGC = ParNew + CMS + Serial Old
-XX:+UseParallelGC = Parallel Scavenge + Parallel Old (1.8默认) 【PS + SerialOld】
-XX:+UseParallelOldGC = Parallel Scavenge + Parallel Old
-XX:+UseG1GC = G1
Linux中没找到默认GC的查看方法，而windows中会打印UseParallelGC
java +XX:+PrintCommandLineFlags -version
通过GC的日志来分辨
Linux下1.8版本默认的垃圾回收器到底是什么？
1.8.0_181 默认（看不出来）Copy MarkCompact
1.8.0_222 默认 PS + PO
参考书籍：《深入理解Java虚拟机》