JVM垃圾收集器

垃圾收集器就是将垃圾回收算法进行了具体的实现，Java虚拟机规范中对于垃圾收集器并没有做任何规定，因此不同的厂商可以自由的实现自己的垃圾收集器。
下图展示的为HotSpot虚拟机的垃圾收集器，如果两个收集器之间有连线，则表示两者可以配合使用，反之，则不能配合使用。

从图中可以看出，Serial、ParNew、Parallel Scavenge三个收集器负责收集新生代；CMS、Serial Old、Parallel Old负责老年代的垃圾收集；G1收集器既可以收集老年代又可以收集新生代。

Serial收集器

该收集器采用“单线程”、串行的方式进行垃圾收集。它这个”单线程”不止是说只是用一条线程来进行工作，最重要的是它进行垃圾收集时，它会暂停掉其他所有的工作线程，直到收集工作结束。新生代采用复制算法，老年代采用标记整理算法。
Serial收集器的优点是简单和高效，但是其在收集时会”Stop The World!”。
Serial收集器工作示意图：

ParNew收集器

ParNew收集器其实就是Serial收集器的多线程版本，除了多线程以外，该收集器与串行收集器相比并没有太多的创新之处，但是它是Server模式下首选的新生代收集器。从图中可以看出，目前除了Serial收集器以外，只有ParNew可以和CMS收集器一起工作，CMS收集器负责老年代的垃圾收集。ParNew收集器也是使用-XX：+UseConcMarkSweepGC选项后的默认新生代收集器，也可以使用-XX：+UseParNewGC 选项来强制指定它。
ParNew收集器运行示意图：

垃圾收集中，并行与并发的含义：

• 并行（Parallel）：指多条垃圾收集线程并行工作，但此时用户线程仍然处于等待状态。
• 并发（Concurrent）：指用户线程与垃圾收集线程同时执行（但不一定是并行的，可能会交替执行），用户程序在继续运行，而垃圾收集程序运行于另一个CPU上。

Parallel Scavenge收集器

该收集器关注的点与CMS不同。CMS等收集器的关注点是尽可能地缩短垃圾收集时用户线程的停顿时间；Parallel Scavenge收集器关注的是吞吐量的可控。
所谓吞吐量就是CPU用于运行用户代码的时间与CPU总消耗时间的比值，即吞吐量=运行用户代码时间/（运行用户代码时间+垃圾收集时间），虚拟机总共运行了100分钟，其中垃圾收集花掉1分钟，那吞吐量就是99%。
停顿时间短更适合与用户交互的程序（CMS），而吞吐量高，则可以更好的利用CPU资源，适合于在后台运算，而不需要太多的交互的任务。（Parallel Scavenge）
在使用时Parallel Scavenge有几个参数可以设置：

• -XX：MaxGCPauseMillis。用来设置垃圾回收停顿间隔，单位是毫秒。
• -XX：GCTimeRatio。直接设置吞吐量，是一个大于0小于100的整数，吞吐量的概念在上面已经介绍过了。
• -XX：+UseAdaptiveSizePolicy。使用自适应的调节策略，虚拟机会根据当前系统的运行情况收集性能监控信息，动态调整这些参数以提供最合适的停顿时间或者最大的吞吐量，这种调节方式称为GC自适应的调节策略（GC Ergonomics）。该策略也是Parallel Scavenge收集器与ParNew收集器的一个重要区别。

上面三个收集器都是新生代的收集器，下面这将会介绍老年代的垃圾收集器。

Serial Old收集器

穿行收集器的老年代版本，使用单线程进行垃圾收集了。在进行垃圾收集时也需要暂停所有用户线程。
Serial Old收集器的运行示意图如图所示：

Parallel Old收集器

该收集器可以与Parallel Scavenge收集器一起工作，在注重“吞吐量优先”以及CPU资源敏感的场合，优先考虑使用Parallel Scavenge加Parallel Old收集器。
Parallel Old收集器的工作流如图所示：

CMS收集器

CMS（Concurrent Mark Sweep)收集器的目标是缩短用户线程的停顿时间，在注重用户交互的服务器端，可以采用该收集器来进行老年代的收集。
该收集器是基于“标记-清除”算法来实现的，总共分为四个步骤：

• 初始标记（CMS initial mark）
• 并发标记（CMS concurrent mark）
• 重新标记（CMS remark）
• 并发清除（CMS concurrent sweep）
  初始标记、重新标记两个步骤仍然需要暂停所有用户线程。初始标记仅仅标记GC Roots能够直接关联的对象，速度很快；并发标记阶段是进行GC RootsTracing的过程；重新标记是标记那些由于用户程序继续运行而产生变化的那部分对象的标记记录。
  由于整个过程中耗时最长的并发标记和并发清除过程收集器线程都可以与用户线程一起工作，所以，从总体上来说，CMS收集器的内存回收过程是与用户线程一起并发执行的。
  
  CMS收集器的缺点：
• CMS收集器对CPU资源非常敏感，由于与用户线程并发运行，因此也降低了系统的吞吐量。
• CMS收集器无法收集浮动垃圾（Floating Garbage），浮动垃圾指的就是由于CMS并发清理阶段用户线程还在运行着，这部分产生的来及只能等到下次GC在进行收集。
• 由于使用的是“标记-清除”算法，在进行清除后可能会产生的大量的内存碎片，从而导致无法进行大对象的分配。

G1收集器

G1收集器的特点如下：

• 并行与并发。G1能充分利用多CPU、 多核环境下的硬件优势，使用多个CPU（CPU或者CPU核心）来缩短Stop-The-World停顿的时间，部分其他收集器原本需要停顿Java线程执行的GC动作，G1收集器仍然可以通过并发的方式让Java程序继续执行。
• 分代收集。与其他收集器一样，分代概念在G1中依然得以保留。 虽然G1可以不需要其他收集器配合就能独立管理整个GC堆，但它能够采用不同的方式去处理新创建的对象和已经存活了一段时间、 熬过多次GC的旧对象以获取更好的收集效果。
• 空间整合。与CMS的“标记—清除”算法不同，G1从整体来看是基于“标记—整理”算法实现的收集器，从局部（两个Region之间）上来看是基于“复制”算法实现的，但无论如何，这两种算法都意味着G1运作期间不会产生内存空间碎片，收集后能提供规整的可用内存。 这种特性有利于程序长时间运行，分配大对象时不会因为无法找到连续内存空间而提前触发下一次GC。
• 可预测的停顿：这是G1相对于CMS的另一大优势，降低停顿时间是G1和CMS共同的关注点，但G1除了追求低停顿外，还能建立可预测的停顿时间模型，能让使用者明确指定在一个长度为M毫秒的时间片段内，消耗在垃圾收集上的时间不得超过N毫秒，这几乎已经是实时Java（RTSJ）的垃圾收集器的特征了。
  G1收集器主要包括初始标记（Initial Marking）、并发标记（Concurrent Marking）、最终标记（Final Marking）、筛选回收（Live Data Counting and Evacuation）。
  G1收集器的工作流程图：
  

总结

本文主要介绍了JVM中的几种垃圾收集器的工作方式和原理，分别对于老年代和新生代进行收集。其中，新生代的垃圾收集器包括Serial 、ParNew 、Parallel Scavenge三种，老年代的垃圾收集器主要有Serial Old、Parallel Old以及CMS收集器。CMS收集器更注重的是降低用户线程的停顿时间，而Parallel Scavenge收集器更注重的是吞吐量（用户线程的运行时间/运行总时间）。最后，对G1收集器进行了介绍，描述了该收集器的一些特点。以后会对这些垃圾收集器进行实验分析，敬请期待！

参考资料

• 深入理解java虚拟机
• JVM 垃圾回收器工作原理及使用实例介绍