垃圾回收器：
Serial收集器：
采用复制算法，是一种单线程的垃圾回收机制，是虚拟机新生代默认情况下的首选收集器。
特点：与其他单线程收集器相比，简单而高效。但是因为在垃圾回收过程中要中断别的工作线程。
Parnew收集器：
Serial收集器的多线程版本，是Server端模式下虚拟机的首选的新生代收集器。
目前只有它能与CMS收集器（第一个真正意义上的并发收集器）进行配合使用。
Parallel Scavenge收集器：
使用的是复制算法，并行的多线程新生代收集器，这个收集器的关注点是：吞吐量，
即 吞吐量=用户代码所占用CUP时间/（用户代码所占用的CUP时间+垃圾回收所占用的CPU时间）。
由于关注的是吞吐量，此垃圾收集器主要用于后台运算量较大交互较少的虚拟机。
SerialOld收集器：
是Serial收集器的老年代版本，他是一个单线程的收集器，使用"标记——整理算法"实现。主要是在Client模式下进行使用，如果在Server模式下有两大用途：
1.配合Parallel Scavenge收集器使用
2.可以作为CMS收集器的备选预案，在Concurren Mark Sweap 下使用。
ParallelOld收集器：
是ParallelScavenge的老年代版本，使用多线程的“标记——整理算法”，在JDK1.6之前，如果新生代使用了Parallel Scavenge收集器，老年代只能使用SerialOld收集器。
CMS收集器：
CMS收集器是一种以获取最短回收停顿时间为目标的收集器，因为现在很大一部分应用是部署在B/S服务器上，
追求的是响应速度，所以这一回收器主要用在Server端，主要实现的是“标记——清除算法”。
CMS收集器回收垃圾的过程可以分为一下四个步骤：
1.初始标记，
2.并发标记，
3.重新标记，
4.并发清除。
其中初始标记和并发标记阶段仍会短暂的暂停业务线程，
初始标记阶段仅仅是进行标记GC Roots能直接关联的对象，速度很快。
并发标记阶段就是进行GC Roots Tracing的过程，
重新标记就是为了重新修正并发标记的过程因程序变动导致标记产生变动的那一部分对象。这个阶段比初始标记稍长的一点，远
远小于并发标记。
CMS收集器的优点：并发收集，低停顿。
缺点：
1. CMS收集器对CPU资源非常敏感，面向并发设计的程序对CPU资源都比较敏感。
在进行并发阶段，回收线程虽然不会停顿程序但是会占用一部分线程（CPU资源），从而导致程序变慢，降低程序的吞吐量，
CMS默认开启的回收线程是（CPU数量+3）/4,也就是在CUP数量超过四个时，回收线程占用CPU资源25%不到，但是当CPU小
于4个时，如果CPU负载本来就比较大时，可能会导致吞吐量降低到50% 一下，这就让人忍受不了了。
为了解决这个问题虚拟机就提供了一种叫做“增量式并发收集器"(Incremental Concurrent Mark Sweap)——iCMS的CMS收集
器的变种,即在垃圾回收线程工作时，不在单独占用CPU时间，而是让业务线程和回收线程抢占CPU时间片 从而让GC线程和用户
线程交替运行， 但是目前版本中“iCMS”已被列为deprecated，不建议再使用。
2.CMS无法处理浮动垃圾
CMS垃圾回收的时候，业务线程也会执行，这个时候业务线程产生的垃圾叫做浮动垃圾（Float garbage）。
所以就导致了要预留一部分内存给浮动垃圾，这就导致了有可能内存使用率才到68%就要启动垃圾回收程序，要是预留的内存
不足，则会出现Concurrent Mode Failure，然后就会启动备用的收集器SerialOld收集器。
3.会出现内存碎片，
CMS是基于“标记——清除算法”,“标记——清除算法”的缺点就是会出现碎片，导致可用的内存空间不连续。导致无法为
占用内存较大的对象进行分配内存。
G1收集器：
相比于CMS收集器有了比较明显的改进：
1.采用"标记——清理算法"，不会出现内存碎片。
2.是他能非常精确地控制停顿，既能让使用者明确指定在一个M毫秒的时间内，消耗在垃圾收集的时间不能超过N毫秒，这几乎是实时JAVA（RTSJ）垃圾收集器的特征。
G1收集器可以在基本不牺牲吞吐量的情况下完成低停顿的内存回收，这是由于它能够极力地避免全区域的垃圾收集，之前的整个垃圾收集进行的范围是整个新生代或者老年代,而G1将整个JAVA堆（包括新生代和老年代）划分为多个大小固定独立的区域，并且跟踪这些区域里面垃圾的堆积程度，在后台维护一个优先级列表，然后在允许的垃圾回收时间内，优先回收垃圾堆积最多的内存区域（Garage First的由来），区域的划分和优先级的区域回收，保证了G1收集器在有限的时间内可以获得最高的收集效率。
垃圾收集的相关参数可以自行进行百度。