1、前言

如果说收集算法是内存回收的方法论，那么垃圾收集器就是内存回收的具体实现

2、Serial收集器

Serial收集器是最基本、发展历史最悠久的收集器，曾经（在JDK 1.3.1之前）是虚拟机新生代收集的唯一选择。它使用单线程进行垃圾回收。它在进行垃圾回收时，必须暂停其他正在工作的线程，直至垃圾回收完成。它也有着优于其他收集器的地方：简单而高效（与其他收集器的单线程比），对于限定单个CPU的环境来说，Serial收集器由于没有线程交互的开销，专心做垃圾收集自然可以获得最高的单线程收集效率。适用于桌面应用场景

3、Parallel收集器

Parallel 收集器使用多线程进行垃圾回收。Parallel 收集器通过并行处理来提高垃圾回收的吞吐量，适用于多核处理器和数据量较大的应用。

4、CMS收集器

CMS（Concurrent Mark Sweep）收集器是一种以获取最短回收停顿时间为目标的收集器。它使用多线程和并发处理来减小对应用程序的暂停影响。

目前很大一部分的Java应用集中在互联网站或者B/S系统的服务端上，这类应用尤其重视服务的响应速度，希望系统停顿时间最短，以给用户带来较好的体验。CMS收集器就非常符合这类应用的需求。

CMS收集器收集垃圾整个过程分为4个步骤，包括：

• 初始标记（CMS initial mark）

• 并发标记（CMS concurrent mark）

• 重新标记（CMS remark）

• 并发清除（CMS concurrent sweep）

其中，初始标记、重新标记这两个步骤仍然需要暂停应用程序。初始标记仅仅只是标记一下GC Roots能直接关联到的对象，速度很快，并发标记阶段就是进行GC Roots Tracing的过程，而重新标记阶段则是为了修正并发标记期间因用户程序继续运作而导致标记产生变动的那一部分对象的标记记录，这个阶段的停顿时间一般会比初始标记阶段稍长一些，但远比并发标记的时间短。

由于整个过程中耗时最长的并发标记和并发清除过程收集器线程都可以与用户线程一起工作，所以，从总体上来说，CMS收集器的内存回收过程是与用户线程一起并发执行的。

5、G1收集器

G1（Garbage-First）收集器是当今收集器技术发展的最前沿成果之一，是一款面向服务端应用的垃圾收集器。HotSpot开发团队赋予它的使命是（在比较长期的）未来可以替换掉JDK 1.5中发布的CMS收集器。G1具备如下特点：

• 并行与并发：G1能充分利用多CPU、多核环境下的硬件优势，使用多个CPU（CPU或者CPU核心）来缩短应用程序停顿的时间

• 分代收集：采用不同的方式去处理新创建的对象和已经存活了一段时间、熬过多次GC的旧对象以获取更好的收集效果

• 空间整合：与CMS的“标记—清理”算法不同，G1从整体来看是基于“标记—整理”算法实现的收集器，从局部（两个Region之间）上来看是基于“复制”算法实现的。这两种算法都意味着G1运作期间不会产生内存空间碎片，收集后能提供规整的可用内存

• 可预测的停顿：建立可预测的停顿时间模型，能让使用者明确指定在一个长度为M毫秒的时间片段内，消耗在垃圾收集上的时间不得超过N毫秒