Java垃圾收集器

说到如何进行Jvm虚拟机优化，第一时间想到应该都是配置堆内存的大小，其次就是 Java 垃圾收集器了。Java垃圾收集器的配置对于Jvm优化来说是一个很重要的选择，选择合适的垃圾收集器可以让Jvm的性能有一个很大的提升。截止Jdk 1.8，一共有7款不同的垃圾收集器。每一款不同的垃圾收集器都有不同的特点，在具体使用的时候，需要根据具体的情况选用不同的垃圾收集器。这几款垃圾收集器之间有如下联系：

下面一一介绍这些垃圾回收器的特点。

Serial收集器

Serial收集器是一个基本的，古老的新生代垃圾收集器。这个垃圾收集器是一个单线程的收集器，在它进行垃圾回收的时候，其他的工作线程都会被暂停，直到它收集结束。这也就是说，如果Jvm参数配置有问题或者内存不够，导致频繁的gc，可能每隔一段时间应用就会暂停响应。如果暂停的时间太长，用户就无法接受了，而且这个过程是不可控制的，是虚拟机在后台自动发起和自动完成的。整个运行过程如下所示：

尽管Serial收集器有如此多的缺点，但是从JDK1.3开始到JDK1.7都一直是默认的运行在Client模式下的新生代收集器。原因在于Serial收集器是一个简单高效的收集器，没有线程切换的开销等等，在一般的Client应用中需要回收的内存也不是很大，垃圾回收停顿的时间不是很长，是可以接受的。所以，Serial收集器对于运行在Client模式下的虚拟机来说是一个很好的选择。

ParNew收集器

ParNew收集器是Serial收集器的多线程版本，除了使用多线程进行垃圾收集之外，其余行为包括Serial收集器可用的所有控制参数、收集算法、Stop The World、对象分配规则、回收策略等都与Serial收集器完全一样，它的工作过程如下：

ParNew收集器除了多线程收集之外，其他与Serial收集器相比并没有太多创新之处，但他却是许多运行在Server模式下的虚拟机中首选的新生代收集器，其中有一个与性能无关但很重要的原因是，除了Serial收集器外，目前只有它能与CMS收集器配合工作。

虽然ParNew收集器是多线程收集，但是它的性能并不一定比Serial收集器好。因为线程切换等开销的因素，在单CPU环境中它的性能是不如Serial收集器的，就算有2个CPU也不一定能说绝对比Serial好。但是随着CPU核数的增多，其最终效果肯定是优于Serial收集器的。

ParNew收集器默认会开启与CPU相同数量的线程来进行垃圾收集，可以通过-XX:ParallelGCThreads参数来限制垃圾收集的线程数。

Parallel Scavenge收集器

Parallel Scavenge收集器是一个新生代收集器，它也是使用复制算法的收集器，也是并行的多线程收集器。看上去与ParNew收集器类似，实际上它们的关注点并不一样。

ParNew收集器主要关注的是回收内存的速度，尽可能地缩短垃圾收集时用户线程的停顿时间，而Parallel Scavenge收集器的目标则是达到一个可控制的吞吐量。

停顿时间越短越适合需要与用户交互的程序，而高吞吐量可以高效率地利用CPU时间，尽快完成程序的任务，主要适合在后台运输而不需要太多交互的任务。

Parallel Scavenge收集器提供了两个参数用于精确控制吞吐量，分别是控制最大垃圾收集停顿时间的-XX:MaxGCPauseMillis参数以及直接设置吞吐量大小的-XX:GCTimeRatio参数。如果对Parallel Scavenge收集器不太熟悉，可以设置-XX:+UseAdaptiveSizePolicy，这个参数是一个开关。打开之后不需要手工指定新生代的大小（-Xmn）、Eden与Survivor区的比例（-XX:SuvivorRatio）、晋升老年代对象大小（-XX:PretenureSizeThreshold）等细节参数了，虚拟机会根据当前系统的运行情况收集性能监控信息，动态调整这些参数以提供最合适的停顿时间或者最大的吞吐量。

Parallel Scavenge收集器的工作过程如图所示：

Serial Old收集器

Serial Old是Serial收集器的老年代版本，它同样是一个单线程收集器，使用“标记-整理”算法。这个收集器的主要意义也是在于给Client模式下的虚拟机使用。如果在Server模式下，那么它主要还有两个用途：一种用途是在JDK1.5以及之前的版本中与Parallel Scavenge收集器搭配使用，另一种用途就是作为CMS收集器的后备预案，在并发收集发生Concurrent Mode Failure时使用。Serial Old收集器的工作过程如图所示：

Parallel Old收集器

Parallel Old收集器是Parallel Scavenge收集器的老年代版本，使用多线程和“标记-整理”算法。这个收集器是在JDK1.6中才开始提供的，在此之前，新生代的Parallel Scavenge收集器一直处于比较尴尬的状态。原因是，如果新生代选择Parallel Scavenge收集器，老年代除了Serial Old收集器外别无选择。直到Parallel Old收集器出现后，“吞吐量优先”收集器终于有了比较名副其实的应用组合，在注重吞吐量以及CPU资源敏感的场合，都可以优先考虑Parallel Scavenge加Parallel Old收集器。Parallel Old收集器的工作过程如图所示：

CMS收集器

CMS收集器是一种以获取最短回收停顿时间为目标的收集器。是基于“标记-清除”算法实现的，它的运作过程相对于前面几种收集器来说更复杂一些，分为4个步骤：

• 初始标记
• 并发标记
• 重新标记
• 并发清除

其中初始标记和重新标记这两个步骤仍然需要“Stop the world”。初始标记仅仅只是标记一下GC Roots能直接关联到的对象，速度很快，并发标记阶段就是GC Roots Tracing的过程，而重新标记阶段则是为了修正并发标记期间因用户程序继续运作而导致标记产生变动的那一部分对象的标记记录，这个阶段的停顿时间一般会比初始标记阶段稍长一些，但远比并发标记的时间短。

由于整个过程中耗时最长的并发标记和并发清除过程收集器线程都可以与用户线程一起工作，所以，从总体上来说，CMS收集器的内存回收过程是用户线程一起并发执行的。CMS收集器的工作过程如图所示：

CMS是一款优秀的收集器，它的优点有：并发收集、低停顿，但它有以下3个明显的缺点：

• CMS收集器对CPU资源非常敏感。在并发阶段，它虽然不会导致用户停顿，但是会因为占用了一部分线程而导致应用程序变慢，总吞吐量会降低。
• CMS收集器无法处理浮动垃圾，可能出现“Concurrent Mode Failure”失败而导致另一次Full GC的产生。由于CMS并发清理阶段用户线程还在运行着，伴随着程序运行自然就还会有新的垃圾不断产生，这部分垃圾出现在标记过程之后，CMS无法在档次收集中处理掉它们，只好留待下一次GC时再清理掉。这一部分垃圾就称为“浮动垃圾”。
• 最后一个缺点是，CMS是基于“标记-清除”算法实现的收集器，容易产生大量的空间碎片，导致没有足够大的连续空间来分配当前对象，不得不提前触发一次Full GC。

G1 收集器

G1收集器是当今收集器技术发展的最前沿成果之一，是一款面向服务端应用的垃圾收集器，它有如下特点：

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

G1收集器的运作大致可划分为以下几个步骤：

• 初始标记
• 并发标记
• 最终标记
• 筛选标记

初始标记阶段仅仅只是标记一下GC Roots能直接关联到的对象，并且修改TAMS（Next Top at Mart Start）的值，让下一阶段用户程序并发运行时，能在正确可用的Region中创建新对象，这阶段需要停顿线程，但耗时很短。

并发标记阶段是从GC Root开始对堆中对象进行可达性分析，找出存活的对象，这阶段耗时较长，但可与用户程序并发执行。

最终标记阶段则是为了修正在并发标记期间因用户程序继续运作而导致标记产生变动的那一部分，这个阶段需要停顿线程，但是可并行执行。

在筛选回收阶段首先对各个Region的回收价值和成本进行排序，根据用户所期望的GC停顿时间来制定回收计划。

G1收集器的工作过程如图所示：