本文内容： serial收集器、parNew收集器、parallel scavenge收集器、serial old收集器、CMS收集器、G1收集器
Serial（串行）垃圾收集器是最基本、发展历史最悠久的收集器，新生代收集器
Serial收集器是虚拟机运行在Client模式下的默认新生代收集器。
JVM在后台自动发起和自动完成的，在用户不可见的情况下，把用户正常的工作线程全部停掉，即GC停顿；会带给用户不良的体验；从JDK1.3到现在，从Serial收集器-》Parallel收集器-》CMS-》G1，用户线程停顿时间不断缩短，但仍然无法完全消除；
serial old和serial一样都是但线程GC收集器，老年代收集器
主要也是给client模式下使用的 如果作用在server模式下，那么它有两个用途：
在jdk1.5之前的版本中与parallel scavenge收集器搭配使用做为CMS收集器的后备预案，在并发收集发生 concurrent mode failure时使用JVM在后台自动发起和自动完成的，在用户不可见的情况下，把用户正常的工作线程全部停掉，即GC停顿；会带给用户不良的体验；从JDK1.3到现在，从Serial收集器-》Parallel收集器-》CMS-》G1，用户线程停顿时间不断缩短，但仍然无法完全消除；
ParNew垃圾收集器是Serial收集器的多线程版本。新生代收集器 其他与Serial收集器相比并没有太多创新之处，但它却是许多运行在Server，模式下的虚拟机中首选的新生代收集器。
parallel scavenge收集器一个并行收集器，看上去和parNew都一样，只是它的关注点与其他收集器不一样。CMS收集器关注的是尽可能缩短垃圾收集时用户线程的停顿时间。而paralle scavenge关注的是可控制的吞吐量。 吞吐量=运行用户代码时间/（运行用户代码时间+垃圾收集时间） 用于精确吞吐量的两个参数：1.控制最大垃圾收集停顿时间参数 2.直接设置吞吐量大小的参数 停顿时间越短就越适合需要与用户交互的程序，良好的响应速度能提升用户体验。高吞吐量则可以高校的利用CUP时间，尽快完成程序的运算任务，适合后台运算而不需要太多交互的任务。 CMS适用于IO密集型的程序。parallel scavenge适用与CUP密集型的程序。
并发标记清理收集器(CMS收集器)的主要目标就是：低应用停顿时间。该目标对于大多数交互式应用很重要，比如web应用。在我们看一下有关JVM的参数之前,让我们简要回顾CMS收集器的操作和使用它时可能出现的主要挑战。 就像parallel scavenge收集器,CMS收集器处理老年代的对象,然而其操作要复杂得多。吞吐量收集器总是暂停应用程序线程，并且可能是相当长的一段时间，然而这能够使该算法安全地忽略应用程序。相比之下，CMS收集器被设计成在大多数时间能与应用程序线程并行执行，仅仅会有一点(短暂的)停顿时间。GC与应用程序并行的缺点就是，可能会出现各种同步和数据不一致的问题。为了实现安全且正确的并发执行，CMS收集器的GC周期被分为了好几个连续的阶段。
空间碎片。 CMS收集器并没有任何碎片整理的机制。因此，应用程序有可能出现这样的情形，即使总的堆大小远没有耗尽，但却不能分配对象——仅仅是因为没有足够连续的空间完全容纳对象。当这种事发生后，并发算法不会帮上任何忙，因此，万不得已JVM会触发Full GC。回想一下，Full GC 将运行吞吐量收集器的算法，从而解决碎片问题——但却暂停了应用程序线程。因此尽管CMS收集器带来完全的并发性，但仍然有可能发生长时间的“stop-the-world”的风险。这是“设计”，而不能避免的——我们只能通过调优收集器来它的可能性。想要100%保证避免”stop-the-world”，对于交互式应用是有问题的。
对象分配率高。如果获取对象实例的频率高于收集器清除堆里死对象的频率，并发算法将再次失败。从某种程度上说，老年代将没有足够的可用空间来容纳一个从年轻代提升过来的对象。这种情况被称为“并发模式失败”，并且JVM会执行堆碎片整理：触发Full GC。
G1参考连接：https://tech.meituan.com/2016/09/23/g1.html G1是一种服务器端的垃圾收集器，应用在多处理器和大容量内存环境中，在实现高吞吐量的同时，尽可能的满足垃圾收集暂停时间的要求 G1收集器的设计目标是取代CMS收集器，它同CMS相比，在以下方面表现的更出色：
G1是一个有整理内存过程的垃圾收集器，不会产生很多内存碎片。G1的Stop The World(STW)更可控G1在停顿时间上添加了预测机制用户可以指定期望停顿时间。