在上一篇《JVM垃圾回收算法介绍》，从算法的角度来描述JVM的垃圾回收有哪些实现的方式。那现在，我们需要探究一下，针对这些算法有哪些对应的垃圾回收器。
在介绍有哪些垃圾回收器之前，需要先明确一下，如何去评价一个垃圾回收器好坏？
其实在我看来主要是以下的三点：
1. 吞吐量：指在应用程序的生命周期内，应用程序所花费的时间和系统总运行时间的比值。系统总运行时间=应用程序耗时+GC 耗时。如果系统运行了 100分钟，GC 耗时 1分钟，那么系统的吞吐量就是 (100-1)/100=99%。从吞吐量这个层面可以大致去评估一个垃圾回收器的效率。
2. 停顿时间：指在进行垃圾回收的时候，中断系统应用线程的时间。当然我们是希望不中断系统的应用线程，让JVM垃圾回收和应用线程同时进行，但是这种情况往往会增大垃圾回收时间，同时也会导致系统的应用线程处理速度变慢，也会导致吞吐量会降低。总之，停顿时间越短，越是我们希望看到的。
3. 垃圾回收频率：指垃圾回收器多长时间会运行一次。一般来说，对于固定的应用而言，垃圾回收器的频率应该是越低越好。通常增大堆空间可以有效降低垃圾回收发生的频率，但是可能会增加回收产生的停顿时间。
按照分代收集的方式，我们把垃圾回收器做如下的划分：
新生代收集器有：Serial 、ParNew、Parallel Scavenge
老年代收集器有：CMS、Serial Old、Paralled Old
新生代和老年代都可以使用的：G1
Serial（新生代串行收集器）
serial收集器有两个突出的特点：1. 它是使用单线程回收，也就是说它在进行垃圾回收的时候只会启动一个线程。2. 在进行回收的时候会暂停系统应用线程（用户线程）。serial是一块比较老的垃圾回收器，在不发生频繁GC的情况下，回收的效率还是非常高的。一般使用serial垃圾回收器，都是在单机版的Client应用中。
如果要使用Serial收集器，需要通过：-XX:+UseSerialGC 参数指定。如果通过：-XX:+PrintGCDetails 打印出GC日志的话，Serial一般都是 [DefNew 开头。
注意一下：我本地电脑的JDK是1.7.0_55，通过 java -XX:+UseSerialGC -XX:+PrintGCDetails 后无法发现有[DefNew 日志的输出.
ParNew（新生代并行收集器）
ParNew收集器也是工作在新生代的，它也有两个突出的特点：1. 它不再像Serial这样，只能单线程回收，它是以多线程的方式进行垃圾回收。2. 只有他能与CMS这块垃圾回收器配合使用，这个其实是跟性能无关，但是也是非常重要的一个作用吧。除此之外，它的回收策略、算法以及参数和串行回收器一样。
如果要使用ParNew收集器，需要通过：-XX:+UseParNewGC 参数指定。如果通过：-XX:+PrintGCDetails 打印出GC日志的话，一般都是 [ParNew 开头。
其实，有时候可以使用-Xloggc:./gc.out 这个参数，将GC的信息输出到当前目录下的gc.out 这个目录中。
Parallel Scavenge（新生代并行收集器）
其实和ParNew一样都是并行收集，但是它更关注“吞吐量”（吞吐量前面已经介绍过）。它也可以使用自适应调节策略帮助完成自动内存的调节。
如果要使用Parallel Scavenge收集器，需要通过：-XX:+UseParallelGC参数指定。如果通过：-XX:+PrintGCDetails 打印出GC日志的话，一般都是 [PSYoungGen 开头。
Serial Old（老年代串行回收器）
Serial Old是Serial收集器的老年代版本，它同样是一个单线程的收集器，使用“标记-整理”算法。如果指定使用Serial Old ，JVM的参数与指定Serial是一样的。
Paralled Old（老年代并行回收器）
Paralllel Old 是 Parallel Scavenge 收集器的老年代版本，是使用并发多线程的方式收集老年代。如果要指定使用Paralled Old，JVM的参数是-XX:+UseParallelOldGC。
CMS（老年代并行回收器）
CMS垃圾回收器比较注重回收的停顿时间，以最短回收停顿时间为目的的收集器。CMS 是 Concurrent Mark Sweep 的缩写，意为并发标记清除，从名称上可以得知，它使用的是标记-清除算法，同时它又是一个使用多线程并发回收的垃圾收集器。一般比较注重服务端性能的时候使用它，它的回收回收过程可以分成四个步骤：1. 初始标记、2. 并发标记、3. 重新标记、4. 并发清除.
初始标记和重新标记这两个步骤任然需要“Stop The World”。初始标记仅仅只是标记一下GC Roots 能直接关联到的对象，速度很快，并发标记阶段就是进行GC RootsTracing的过程，而重新标记阶段就是为了修正并发标记期间因用户程序继续运行而导致标记产生变动的那一部分对象的标记记录，这个阶段的停顿时间一般会比初始标记阶段稍微长一些，但远比并发标记的时间短。由于整个过程中耗时最长的并发标记和并发清楚过程，所以从总体上说，CMS收集器的内存回收过程是与用户线程一起并发执行的。
它同样也是有缺点的：
1. 虽然在并发清理过程不会导致线程停顿，但是会因为占用了一部分线程而导致应用程序变慢，导致总的吞吐量会降低。尤其当cpu不足4个的时候，CMS对用户程序的影响可能变得很大。
2. CMS收集器无法处理浮动垃圾。由于CMS并发清理阶段用户线程还在运行，伴随程序裕兴自然就会产生新的垃圾，这一部分垃圾出现在标记过程之后，CMS无法再当次收集中处理掉他们，只好留在下一次GC时再清理掉。由于垃圾收集阶段用户线程还需要运行，那也就需要预留出足够的内存空间给用户线程使用，因此CMS收集器不能像其他收集器那样等到老年代几乎完全被填满的时候才进行收集，需要预留一部分空间提供并发收集时的程序运行使用。在JDK1.5中，默认设置的是68%的空间后会被激活，这是一个偏保守的方案。可以自己调节这个比例。如果在CMS运行期间预留的内存无法满足程序需要，这个时候就会出现”Comcurrent Mode Failure”失败，这是细腻集就会启动后背预案，临时启用Serial Old 收集器来重新进行老年代的垃圾收集，这样停顿时间就很长了。
3. CMS使用的是“标记-清楚”算法实现的收集器。这种算法是不带内存整理的，必然会产生很多的内存碎片。如果要分配一个大的对象，但是这时无法满足内存分配，就必须提前触发一次FULLGC，那一般情况下CMS收集器如果需要提前进行FULL GC的时候会开启内存碎片的合并整理，整理的过程是无法并发执行的，这个时候停顿的时间就会变长。
如果要使用CMS收集器，需要通过：-XX:+UseConcMarkSweepGC参数指定。如果通过：-XX:+PrintGCDetails 打印出GC日志的话，一般都是 [CMS 开头。
G1
G1收集器既可以收集新生代，也可以收集老年代。其实G1收集器在实现的时候将整个内存区间并不是划分成了严格的新生代和老年代。它将整个Java堆划分成为多个大小相等的独立区域，虽然还保留有新生代和老年代的概念，但是新生代和老年代不再是物理隔离的了，他们都是一部分Region的集合。G1主要关注点在于：1. 并行与并发的性能、2. 能够独立的管理Java堆、3. 内存空间整合、4. 可预测的停顿。
如果要使用CMS收集器，需要通过：-XX:+UseG1GC参数指定。G1一般的日志中都是garbage-first 这样的标示。
据说Java9的默认垃圾收集回收器将会改成G1，所以G1还是值得期待的。
