单线程GC收集器包括Serial和SerialOld这两款收集器，分别用于年轻代和老年代的垃圾收集工作。
多线程收集器还包括Parallel Scavenge和ParallelOld收集器，这两款也分别用于年轻代和老年代的垃圾收集工作，不同的是，它们是两款可以利用多核优势的多线程收集器。
相对来说更加复杂的还有CMS收集器。这款收集器，在运行的时候会分多个阶段进行垃圾收集，而且在一些阶段是可以和应用线程并行运行的，提高了这款收集器的收集效率。
Serial收集器
Serial收集器是一款年轻代的垃圾收集器，使用标记-复制垃圾收集算法。Serial收集器只能使用一条线程进行垃圾收集工作，并且在进行垃圾收集的时候，所有的工作线程都需要停止工作，等待垃圾收集线程完成以后，其他线程才可以继续工作。
ParNew收集器
ParNew垃圾收集器是Serial收集器的多线程版本，使用标记-复制垃圾收集算法。为了利用CPU多核多线程的优势，ParNew收集器可以运行多个收集线程来进行垃圾收集工作，
作为一款多线程收集器，当它运行在单CPU的机器上的时候，由于不能利用多核的优势，在线程收集过程中可能会出现频繁上下文切换，导致额外的开销，所以在单CPU的机器上，ParNew收集器的性能不一定好于Serial这款单线程收集器。如果机器是多CPU的，那么ParNew还是可以很好的提高GC收集的效率的。
ParNew收集器默认开启的垃圾收集线程数是和当前机器的CPU数量相同的，为了控制GC收集线程的数量，可以通过参数-XX:ParallelGCThreads来控制垃圾收集线程的数量。
Parallel Scavenge收集器
Parallel Scavenge收集器是是一款年轻代的收集器，它使用标记-复制垃圾收集算法。和ParNew一样，它也会一款多线程的垃圾收集器，但是它又和ParNew有很大的不同点。
Parallel Scavenge收集器和其他收集器的关注点不同。其他收集器，比如ParNew和CMS这些收集器，它们主要关注的是如何缩短垃圾收集的时间。而Parallel Scavenge收集器关注的是如何控制系统运行的吞吐量。这里说的吞吐量，指的是CPU用于运行应用程序的时间和CPU总时间的占比，吞吐量 = 代码运行时间 / (代码运行时间 + 垃圾收集时间)。如果虚拟机运行的总的CPU时间是100分钟，而用于执行垃圾收集的时间为1分钟，那么吞吐量就是99%。
直观上，好像以缩短垃圾收集的停顿时间为目的和以控制吞吐量为目的差不多，但是适用的场景却不同。对于那些桌面应用程序，为了得到良好的用户体验，在交互过程中，需要得到快速的响应，所以系统的停顿时间要尽可能的快以避免影响到系统的响应速度，只要保证每次停顿的时间很短暂，假设每次停顿时间为10ms，那么即使发生很多次的垃圾收集过程，假设1000次，也不会影响到系统的响应速度，不会影响到用户的体验。对于一些后台计算任务，它不需要和用户进行交互，所以短暂的停顿时间对它而言并不需要，对于计算任务而言，更好的利用CPU时间，提高计算效率才是需要的，所以假设每次停顿时间相对很长，有100ms，而由于花费了很长的时间进行垃圾收集，那么垃圾收集的次数就会降下来，假设只有5次，那么显然，使用以吞吐量为目的的垃圾收集器，可以更加有效的利用CPU来完成计算任务。所以，在用户界面程序中，使用低延迟的垃圾收集器会有很好的效果，而对于后台计算任务的系统，高吞吐量的收集器才是首选。
Parallel Scavenge收集器提供了两个参数用于控制吞吐量。-XX:MaxGCPauseMillis用于控制最大垃圾收集停顿时间，-XX:GCTimeRatio用于直接控制吞吐量的大小。MaxGCPauseMillis参数的值允许是一个大于0的整数，表示毫秒数，收集器会尽可能的保证每次垃圾收集耗费的时间不超过这个设定值。但是如果这个这个值设定的过小，那么Parallel Scavenge收集器为了保证每次垃圾收集的时间不超过这个限定值，会导致垃圾收集的次数增加和增加年轻代的空间大小，垃圾收集的吞吐量也会随之下降。GCTimeRatio这个参数的值应该是一个0-100之间的整数，表示应用程序运行时间和垃圾收集时间的比值。如果把值设置为19，即系统运行时间 : GC收集时间 = 19 : 1，那么GC收集时间就占用了总时间的5%(1 / (19 + 1) = 5%)，该参数的默认值为99，即最大允许1%(1 / (1 + 99) = 1%)的垃圾收集时间。
Parallel Scavenge收集器还有一个参数：-XX:UseAdaptiveSizePolicy。这是一个开关参数，当开启这个参数以后，就不需要手动指定新生代的内存大小(-Xmn)、Eden区和Survivor区的比值(-XX:SurvivorRatio)以及晋升到老年代的对象的大小(-XX:PretenureSizeThreshold)等参数了，虚拟机会根据当前系统的运行情况动态调整合适的设置值来达到合适的停顿时间和合适的吞吐量，这种方式称为GC自适应调节策略。
Parallel Scavenge收集器也是一款多线程收集器，但是由于目的是为了控制系统的吞吐量，所以这款收集器也被称为吞吐量优先收集器。
Serial Old收集器
Serial Old收集器是Serial收集器的老年代版本，它也是一款使用"标记-整理"算法的单线程的垃圾收集器。这款收集器主要用于客户端应用程序中作为老年代的垃圾收集器，也可以作为服务端应用程序的垃圾收集器，当它用于服务端应用系统中的时候，主要是在JDK1.5版本之前和Parallel Scavenge年轻代收集器配合使用，或者作为CMS收集器的后备收集器。
Parallel Old收集器
Parallel Old收集器是Parallel Scavenge收集器的老年代版本，使用"标记-整理"算法。这个收集器是在JDK1.6版本中出现的，所以在JDK1.6之前，新生代的Parallel Scavenge只能和Serial Old这款单线程的老年代收集器配合使用。Parallel Old垃圾收集器和Parallel Scavenge收集器一样，也是一款关注吞吐量的垃圾收集器，和Parallel Scavenge收集器一起配合，可以实现对Java堆内存的吞吐量优先的垃圾收集策略。
Parallel Old垃圾收集器的工作原理和Parallel Scavenge收集器类似。
CMS收集器
CMS收集器是目前老年代收集器中比较优秀的垃圾收集器。CMS是Concurrent Mark Sweep，从名字可以看出，这是一款使用"标记-清除"算法的并发收集器。CMS垃圾收集器是一款以获取最短停顿时间为目标的收集器。由于现代互联网中的应用，比较重视服务的响应速度和系统的停顿时间，所以CMS收集器非常适合在这种场景下使用。
- 初始标记(CMS initial mark)阶段
- 并发标记(CMS concurrent mark)阶段
- 重新标记(CMS remark)阶段
- 并发清除(CMS concurrent sweep)阶段
从图中可以看出，在这4个阶段中，初始标记和重新标记这两个阶段都是只有GC线程在运行，用户线程会被停止，所以这两个阶段会发送STW(Stop The World)。初始标记阶段的工作是标记GC Roots可以直接关联到的对象，速度很快。并发标记阶段，会从GC Roots 出发，标记处所有可达的对象，这个过程可能会花费相对比较长的时间，但是由于在这个阶段，GC线程和用户线程是可以一起运行的，所以即使标记过程比较耗时，也不会影响到系统的运行。重新标记阶段，是对并发标记期间因用户程序运行而导致标记变动的那部分记录进行修正，重新标记阶段耗时一般比初始标记稍长，但是远小于并发标记阶段。最终，会进行并发清理阶段，和并发标记阶段类似，并发清理阶段不会停止系统的运行，所以即使相对耗时，也不会对系统运行产生大的影响。
由于并发标记和并发清理阶段是和应用系统一起执行的，而初始标记和重新标记相对来说耗时很短，所以可以认为CMS收集器在运行过程中，是和应用程序是并发执行的。由于CMS收集器是一款并发收集和低停顿的垃圾收集器，所以CMS收集器也被称为并发低停顿收集器。
虽然CMS收集器可以是实现低延迟并发收集，但是也存在一些不足。
首先，CMS收集器对CPU资源非常敏感。对于并发实现的收集器而言，虽然可以利用多核优势提高垃圾收集的效率，但是由于收集器在运行过程中会占用一部分的线程，这些线程会占用CPU资源，所以会影响到应用系统的运行，会导致系统总的吞吐量降低。CMS默认开始的回收线程数是(Ncpu + 3) / 4，其中Ncpu是机器的CPU数。所以，当机器的CPU数量为4个以上的时候，垃圾回收线程将占用不少于%25的CPU资源，并且随着CPU数量的增加，垃圾回收线程占用的CPU资源会减少。但是，当CPU资源少于4个的时候，垃圾回收线程占用的CPU资源的比例会增大，会影响到系统的运行，假设有2个CPU的情况下，垃圾回收线程将会占据超过50%的CPU资源。所以，在选用CMS收集器的时候，需要考虑，当前的应用系统，是否对CPU资源敏感。
其次，CMS收集器在处理垃圾收集的过程中，可能会产生浮动垃圾，由于它无法处理浮动垃圾，所以可能会出现Concurrent Mode Failure问题而导致触发一次Full GC。所谓的浮动垃圾，是由于CMS收集器的并发清理阶段，清理线程是和用户线程一起运行，如果在清理过程中，用户线程产生了垃圾对象，由于过了标记阶段，所以这些垃圾对象就成为了浮动垃圾，CMS无法在当前垃圾收集过程中集中处理这些垃圾对象。由于这个原因，CMS收集器不能像其他收集器那样等到完全填满了老年代以后才进行垃圾收集，需要预留一部分空间来保证当出现浮动垃圾的时候可以有空间存放这些垃圾对象。在JDK 1.5中，默认当老年代使用了68%的时候会激活垃圾收集，这是一个保守的设置，如果在应用中老年代增长不是很快，可以通过参数"-XX:CMSInitiatingOccupancyFraction"控制触发的百分比，以便降低内存回收次数来提供性能。在JDK 1.6中，CMS收集器的激活阀值变成了92%。如果在CMS运行期间没有足够的内存来存放浮动垃圾，那么就会导致"Concurrent Mode Failure"失败，这个时候，虚拟机将启动后备预案，临时启动Serial Old收集器来对老年代重新进行垃圾收集，这样会导致垃圾收集的时间边长，特别是当老年代内存很大的时候。所以对参数"-XX:CMSInitiatingOccupancyFraction"的设置，过高，会导致发生Concurrent Mode Failure，过低，则浪费内存空间。
CMS的最后一个问题，就是它在进行垃圾收集时使用的"标记-清除"算法。上一篇文章介绍垃圾回收原理的时候，我们讲到"标记-清除"算法，在进行垃圾清理以后，会出现很多内存碎片，过多的内存碎片会影响大对象的分配，会导致即使老年代内存还有很多空闲，但是由于过多的内存碎片，不得不提前触发垃圾回收。为了解决这个问题，CMS收集器提供了一个"-XX:+UseCMSCompactAtFullCollection"参数，用于CMS收集器在必要的时候对内存碎片进行压缩整理。由于内存碎片整理过程不是并发的，所以会导致停顿时间变长。"-XX:+UseCMSCompactAtFullCollection"参数默认是开启的。虚拟机还提供了一个"-XX:CMSFullGCsBeforeCompaction"参数，来控制进行过多少次不压缩的Full GC以后，进行一次带压缩的Full GC，默认值是0，表示每次在进行Full GC前都进行碎片整理。
虽然CMS收集器存在上面提到的这些问题，但是毫无疑问，CMS当前仍然是非常优秀的垃圾收集器。
本文内容主要是学习周志明老师的《深入理解Java虚拟机》一书的学习笔记，仅作学习巩固整理知识点使用，在此感谢周老师。