Serial Old收集器
Serial Old收集器时Serial收集器的老年代版本。
同样是单线程收集器。
使用“标记-整理”算法。
默认也是给client模式下使用的老年单收集器。
该收集器可以作为CMS收集器的后备预案；
Parallel Old收集器
Parallel Old是Parallel Scavenger收集器的老年代版本。
使用多线程和“标记-整理”算法。
Parallel Old只能与Parallel Scavenger收集器一起配合使用。
CMS收集器
CMS收集器是一种以获得最短回收停顿时间为目标的收集器。
CMS非常适用于B/S系统服务器上，因为它的停顿时间短，GC对用户交互影响下。
CMS收集器使用“标记-清除”算法，主要分为以下几个步骤：
- 初始标记
该步骤需要Stop The World，即停止用户线程运行。
该标记仅仅只是标记以下GC Roots能直接关联到的对象，速度很快。
- 并发标记
是对GC Roots Tracing的过程
- 重新标记
该步骤需要Stop The World，即停止用户线程运行。
该过程是为了修改并发标记期间因为程序继续运行而导致标记产生变化的那一步对象的标记记录。这个阶段一般比初始标记时间稍长，但是远比并发标记时间短。
- 并发清除
耗时最长的并发标记和并发清除过程收集线程都可以与用户线程并发运行。
CMS收集主要优势体现在并发收集、低停顿。
CMS缺点：
- 对CPU资源比较敏感
因为“并发标记”、“并发清除”两个步骤的收集线程与用户线程并发运行，会占用一部分CPU资源。CMS默认回收线程数（CPU数量+3)/4。
为了解决以上问题，虚拟机提供了一种新的收集器，即CMS收集器的变种（i-CMS）,该收集器在并发标记、并发清除两个阶段可以让GC线程与用户新城交替运行，尽量减少GC线程的独占资源时间，这样整理GC过程会变成，但是对用户线程影响会变小。
i-CMS收集器已经被标记为过期。
- CMS收集无法处理浮动垃圾
CMS浮动垃圾可能导致出现“Concurrent Mode Failure”失败而导致另一次Full GC的产生。
由于CMS并发清除阶段用户线程还在运行，伴随着可能产生新的垃圾，这一部分垃圾在标记后，CMS无法在当次收集中处理掉它们，只能留到下一次GC中，这一部分垃圾称为浮动垃圾。
同时垃圾清除阶段，用户线程也在并发运行，所以用户线性也需要一部分内存，导致必须为用户线程预留一部分内存，但是由于浮动垃圾的存在，可能导致下一次GC的并发清除阶段，无法预留足够的内存为用户线程使用，所以下次如果没有足够内存为用户线程使用，会出现“Concurrent Mode Failure”失败，这个失败将导致虚拟机启用备用方案，即Serial Old收集器来重新进行老年代的垃圾回收，这部分停顿时间会比较长。
- CMS是一个基于“标记-清除”算法的垃圾回收器
标记-清除算法会产生垃圾碎片，导致内存比较零碎，如果要分配大内存的对象，可能没有足够大的内存碎片为对象分配内存。
所以CMS提供了一个配置-XX：CMSFUllGCsBeforeCompaction参数，这个参数可以设置执行多少次不压缩的Full GC后，跟着进行一次带压缩的收集。