- Serial收集器
- Serial收集器：是最基本、最悠久的新生代收集器，是一个单线程的收集器，并且在垃圾回收时还必须暂停其他所有的工作线程，直到它结束为止。
- 下图示意了Serial/SerialOld收集器的运行过程：
- 按照上述的说法是不是会觉得Serial收集器很鸡肋，但实际到现在为止它依然是虚拟机运行在Client模式下的默认新生代收集器。
- 它优势在于：简单高效（与其他收集器的单线程对比），对于单个CPU环境而言，Serial没有线程交互的开销，可以获得更高的单线程收集效率。
ParNew收集器
- 其实就是Serial的多线程版本的新生代收集器，其可用的所有控制参数（例如：-XX:SurvivorRatio、-XX:PretenureSizeThreshold、-XX:HandlePromotionFailure等）、收集算法、Stop The World、对象分配规则、回收策略等都与Serial完全一样。工作示意图如下：
ParNew相比Serial，则是较多的运行在Server模式下的虚拟机中首选的新生代收集器。而且还有一个重要的原因，除了Serial外，目前只有他能与CMS收集器（JDK1.5推出，是HotSpot第一款真正意义上的并发收集器）搭配工作。ParNew可以使用-XX:ParallelGCThreads参数来限制垃圾收集的线程数。
Parallel Scavange收集器
- 其也是一个多线程新生代收集器（不能与CMS配合工作），他的特点是关注点与其他收集器不同，CMS等收集器的关注点是尽可能缩短垃圾收集时用户线程的停顿时间，而他的目标是达到一个可控制的吞吐量。其有两个参数用于精确控制吞吐量，分别是最大垃圾收集停顿时间 -XX:MaxGCPauseMillis（数值太小虽然停顿时间会下降，但吞吐量也会下降）以直接设置及吞吐量大小的-XX:GCTimeRatio。此外还有一个设置自适应调节策略的参数-XX:UseAdaptiveSizePolicy。这也是其和ParNew的一个很重要的区别。
Serial Old收集器
- 是Serial的老年代的单线程收集器，采用“标记-整理”算法进行垃圾回收。同样也是主要在Client模式下使用。但是如果是在Server模式下，那么主要有两大用途：一是在JDK1.5前与Parallel Scavenge收集器搭配使用。另一种是作为CMS的后备预案，在并发收集发生ConCurrent Mode Failure时使用。
Parallel Old收集器
- 是Parallel Scavenge收集器的多线程老年代版本，使用“标记-整理”算法进行垃圾回收，在此之前Parallel Scavenge只能搭配Serial Old收集器，未能充分获得吞吐量最大化的效果，因此在注重吞吐量以及CPU资源敏感的场合，可优先考虑Parallel Scavenge加Parallel Old收集器。
CMS（Concurrent Mark Sweep）收集器
- 从名字就可以看出该收集器用了“标记-清除”算法，整个过程分为4部分：初始标记，并发标记，重新标记，并发清除。
- 初始标记和重新标记仍然需要“Stop The World”。初始标记只是标记一下GC Roots能直接关联到的对象，速度很快。并发标记是进行GC Roots Tracing的过程，重新标记是为了修正并发标记期间因用户程序运行而导致的标记变动的那一部分对象的标记记录，该阶段停顿时间比初始标记长但远比并发标记短。运行示意图如下：
- CMS虽然已经是基本实现了并发，有着并发收集、低停顿的优点，但同时也有3处明显的缺点：
- 对CPU资源特别敏感。CMS默认启动的回收线程为（CPU数量+3）/4，当CPU数量不足4个时（譬如2个），CMS对用户程序的影响就很大，为了应付这种情况，虚拟机提供了一种称为“增量式并发收集器”的CMS收集器变种。但因为效果一般，已不提倡使用。
- CMS收集器无法处理浮动垃圾，可能导致“Concurrent Mode Failure”（简称CMF）失败而导致另一次Full GC的产生（在并发清理时由用户程序运行产生的没有在本次标记过程中标记的垃圾，这些垃圾只能留在下一次GC处理）。因此需要预留一些空间提供并发收集时的程序运作使用。可以通过适当的调高参数-XX:CMSInitiatingOccupancyFration 的值来提高触发老年代回收的百分比，以便降低回收次数从而获得更好的性能。在JDK 1.6，CMS收集器的启动阈值已经提升至92%。当出现“CMF”失败时，虚拟机会启动后备预案：临时启动Serial Old收集器来重新进行老年代的垃圾收集，这样停顿的时间会很长。
- 由于CMS收集器采用的是“标记-清除”算法，所以会有大量的空间碎片。这会给大对象分配空间带来麻烦，当在老年代还有很大空间剩余却找不到足够大的连续空间来分配给当前对象时，便不得不触发一次Full GC。为了解决这个问题，CMS收集器提供了 -XX:UseCMSCompactAtFullCollection开关参数（默认开启），用于在要顶不住要进行Full GC时进行空间碎片的合并，但该过程是无法并发的。
G1收集器
- 是当前收集器技术发展最前言成果之一。它被视为JDK 1.7中HotSpot虚拟机的一个重要精华特征。G1与其他收集器相比具备如下特点：
- 并行与并发：可以充分利用多CPU、多核环境下来缩短“Stop The World”的停顿时间。
- 分代收集：不需要其他收集器配合就能独立管理整个GC堆，采取不同的方式去处理新创建的对象和已经存活了一段时间、熬过多次GC的旧对象以获得更好的收集效果。
- 空间整合：从整体看是基于“标记-整理”算法，从局部是基于“复制”算法，但不论哪种两者都不用产生空间碎片，有利于程序的长时间运行。
- 可预测的停顿：能建立可预测的停顿时间模型，使使用者指定在一个长度为M毫秒的时间片内，消耗在垃圾收集上的时间不得超过N毫秒，这几乎是实时java（RTSJ）的垃圾收集器的特征了。
- 使用G1收集器时，它将java堆划分为多个大小相同的独立区域（Region），虽然还保留有新生代和老年代的概念，但两者不再是物理隔离了，他们都是一部分Region（不需要连续）的集合。
- G1收集器之所以能建立可预测的停顿时间模型，是因为他会跟踪各个Region里面的垃圾堆积的价值大小，在后台维护一个优先列表，每次根据允许的收集时间，优先收集价值最大的Region。这种方式保证了G1收集器在有限的时间内可以获取尽可能高的收集效率。