垃圾收集器


如果说收集算法是内存回收的方法论,垃圾收集器就是内存回收的具体实现。

垃圾收集器_多线程

上图展示了7种作用于不同分代的收集器(包括JDK 1.6_Update14后引入的Early Access版G1收集器),如果两个收集器之间存在连线,就说明它们可以搭配使用。

1、Serial收集器(单线程、复制算法)

Serial收集器是最基本、历史最悠久的收集器,曾经(在JDK 1.3.1之前)是虚拟机新生代收集的唯一选择。这个收集器是一个​单线程​的收集器,但它的“单线程”的意义并不仅仅是说明它只会使用一个CPU或一条收集线程去完成垃圾收集工作,更重要的是在​它进行垃圾收集时,必须暂停其他所有的工作线程​(Sun将这件事情称之为“Stop The World”),​直到它收集结束​。这项工作实际上是由虚拟机在后台自动发起和自动完成的,在用户不可见的情况下把用户的正常工作的线程全部停掉,这对很多应用来说都是难以接受的。

Serial收集器似乎是一个老而无用,食之无味弃之可惜的鸡肋了,但实际上到现在为止,它依然是虚拟机运行在Client模式下的默认新生代收集器。

它也有着优于其他收集器的地方:​简单而高效(与其他收集器的单线程比),对于限定单个CPU的环境来说,Serial收集器由于没有线程交互的开销,专心做垃圾收集自然可以获得最高的单线程收集效率。

在用户的桌面应用场景中,分配给虚拟机管理的内存一般来说不会很大,收集几十兆甚至一两百兆的新生代(仅仅是新生代使用的内存,桌面应用基本上不会再大了),停顿时间完全可以控制在几十毫秒最多一百多毫秒以内,只要不是频繁发生,这点停顿是可以接受的。所以,Serial收集器对于运行在Client模式下的虚拟机来说是一个很好的选择。

Serial/Serial Old收集器运行示意图

垃圾收集器_多线程_02

2、Serial Old收集器(单线程、标记-整理算法)

Serial Old是Serial收集器的老年代版本,它同样是一个​单线程​收集器,使用“​标记-整理​”算法。这个收集器的主要意义也是被Client模式下的虚拟机使用。如果在Server模式下,它主要还有两大用途:


  1. 一个是在JDK 1.5及之前的版本中与Parallel Scavenge收集器搭配使用 ,
  2. 另外一个就是作为CMS收集器的后备预案,在并发收集发生Concurrent Mode Failure的时候使用。

3、ParNew收集器(多线程、复制算法)

ParNew收集器其实就是Serial收集器的​多线程​版本,除了使用多条线程进行垃圾收集之外,其余行为包括Serial收集器可用的所有控制参数(例如:-XX:SurvivorRatio、-XX:PretenureSizeThreshold、-XX:HandlePromotionFailure等)、收集算法、Stop The World、对象分配规则、回收策略等都与Serial收集器完全一样,实现上这两种收集器也共用了相当多的代码。

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

ParNew收集器在单CPU的环境中绝对不会有比Serial收集器更好的效果​,甚至由于存在线程交互的开销,该收集器在通过超线程技术实现的两个CPU的环境中都不能百分之百地保证能超越Serial收集器。

当然,随着可以使用的CPU的数量的增加,它对于GC时系统资源的利用还是很有好处的。

ParNew/Serial Old收集器运行示意图

垃圾收集器_老年代_03

4、Parallel Scavenge收集器(多线程、复制算法)

Parallel Scavenge收集器也是一个新生代收集器,它也是使用​复制算法​的收集器,又是并行的​多线程​收集器, Parallel Scavenge收集器的特点是它的关注点与其他收集器不同,CMS等收集器的关注点尽可能地缩短垃圾收集时用户线程的停顿时间,而​Parallel Scavenge收集器的目标则是达到一个可控制的吞吐量(Throughput)。

所谓吞吐量就是CPU用于运行用户代码的时间与CPU总消耗时间的比值,即

吞吐量=运行用户代码时间/(运行用户代码时间+垃圾收集时间)

虚拟机总共运行了100分钟,其中垃圾收集花掉1分钟,那吞吐量就是99%。

停顿时间越短就越适合需要与用户交互的程序,良好的响应速度能提升用户的体验;而高吞吐量则可以最高效率地利用CPU时间,尽快地完成程序的运算任务,主要适合在后台运算而不需要太多交互的任务。 Parallel Scavenge收集器提供了两个参数用于精确控制吞吐量,分别是控制最大垃圾收集停顿时间的​​-XX:MaxGCPauseMillis​​​参数及直接设置吞吐量大小的​​-XX:GCTimeRatio​​参数。

​MaxGCPauseMillis​​参数允许的值是一个大于0的毫秒数,收集器将尽力保证内存回收花费的时间不超过设定值。不过大家不要异想天开地认为如果把这个参数的值设置得稍小一点就能使得系统的垃圾收集速度变得更快,​GC停顿时间缩短是以牺牲吞吐量和新生代空间来换取的​:系统把新生代调小一些,收集300MB新生代肯定比收集500MB快吧,这也直接导致垃圾收集发生得更频繁一些,原来10秒收集一次、每次停顿100毫秒,现在变成5秒收集一次、每次停顿70毫秒。停顿时间的确在下降,但吞吐量也降下来了。

​GCTimeRatio​​参数的值应当是一个大于0小于100的整数,也就是垃圾收集时间占总时间的比率,相当于是吞吐量的倒数。如果把此参数设置为19,那允许的最大GC时间就占总时间的5%(即1/(1+19)),默认值为99,就是允许最大1%(即1/(1+99))的垃圾收集时间。

Parallel Scavenge/Parallel Old收集器运行示意图

垃圾收集器_多线程_04

5、Parallel Old收集器(多线程、标记-整理算法)

Parallel Old是Parallel Scavenge收集器的老年代版本​,使用​多线程​和“​标记-整理​”算法。

由于单线程的老年代Serial Old收集器在服务端应用性能上的“拖累”,即便使用了Parallel Scavenge收集器也未必能在整体应用上获得吞吐量最大化的效果,又因为老年代收集中无法充分利用服务器多CPU的处理能力,在老年代很大而且硬件比较高级的环境中,这种组合的吞吐量甚至还不一定有ParNew加CMS的组合“给力”。

直到Parallel Old收集器出现后,“吞吐量优先”收集器终于有了比较名副其实的应用组合,在注重吞吐量及CPU资源敏感的场合,都可以优先考虑Parallel Scavenge加Parallel Old收集器。

6、CMS收集器(并发、低停顿、标记-清楚算法)

CMS(Concurrent Mark Sweep)收集器是一种以获取​最短回收停顿时间​为目标的收集器。

垃圾收集器_多线程_05

从名字(包含“Mark Sweep”)上就可以看出CMS收集器是基于“​标记-清除​”算法实现的,它的运作过程相对于前面几种收集器来说要更复杂一些,整个过程分为4个步骤,包括:

1. 初始标记(CMS initial mark)

2. 并发标记(CMS concurrent mark)

3. 重新标记(CMS remark)

4. 并发清除(CMS concurrent sweep)

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

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

CMS是一款优秀的收集器,它的最主要优点在名字上已经体现出来了:​并发收集、低停顿​,Sun的一些官方文档里面也称之为并发低停顿收集器(Concurrent Low Pause Collector)。

但是CMS还远达不到完美的程度,它有以下三个显著的缺点:

1)CMS收集器对CPU资源非常敏感,会占用大量的CPU资源

其实,面向并发设计的程序都对CPU资源比较敏感。在并发阶段,它虽然不会导致用户线程停顿,但是​会因为占用了一部分线程(或者说CPU资源)而导致应用程序变慢​,总吞吐量会降低。CMS默认启动的回收线程数是(CPU数量+3)/4,也就是当CPU在4个以上时,并发回收时垃圾收集线程最多占用不超过25%的CPU资源。但是当CPU不足4个时(譬如2个),那么CMS对用户程序的影响就可能变得很大,如果CPU负载本来就比较大的时候,还分出一半的运算能力去执行收集器线程,就可能导致用户程序的执行速度忽然降低了50%,这也很让人受不了。

2)CMS收集器无法处理浮动垃圾(Floating Garbage)

CMS收集器无法处理浮动垃圾(Floating Garbage),可能出现“Concurrent Mode Failure”失败而导致另一次Full GC的产生。​由于CMS并发清理阶段用户线程还在运行着,伴随程序的运行自然还会有新的垃圾不断产生,这一部分垃圾出现在标记过程之后,CMS无法在本次收集中处理掉它们,只好留待下一次GC时再将其清理掉​。这一部分垃圾就称为“​浮动垃圾​”。也是由于在垃圾收集阶段用户线程还需要运行,即还需要预留足够的内存空间给用户线程使用,因此CMS收集器不能像其他收集器那样等到老年代几乎完全被填满了再进行收集,需要预留一部分空间提供并发收集时的程序运作使用。

在默认设置下,CMS收集器在老年代使用了68%的空间后就会被激活,这是一个偏保守的设置,如果在应用中老年代增长不是太快,可以适当调高参数-XX:CMSInitiatingOccupancyFraction的值来提高触发百分比,以便降低内存回收次数以获取更好的性能。要是CMS运行期间预留的内存无法满足程序需要,就会出现一次“Concurrent Mode Failure”失败,这时候虚拟机将启动后备预案:临时启用Serial Old收集器来重新进行老年代的垃圾收集,这样停顿时间就很长了。所以说参数-XX:CMSInitiatingOccupan cyFraction设置得太高将会很容易导致大量“Concurrent Mode Failure”失败,性能反而降低。

3)CMS是一款基于“标记-清除”算法实现的收集器

这意味着收集结束时会产生​大量空间碎片​。空间碎片过多时,将会给大对象分

配带来很大的麻烦,往往会出现老年代还有很大的空间剩余,但是无法找到足够大的连续空间来分配当前对象,不得不提前触发一次Full GC。

7、G1收集器(标记-整理算法)

G1收集器是垃圾收集器理论进一步发展的产物,它与前面的CMS收集器相比有两个显著的改进:


  1. 一是G1收集器是基于“标记-整理”算法实现的收集器,也就是说它不会产生空间碎片,这对于长时间运行的应用系统来说非常重要。
  2. 二是它可以非常精确地控制停顿,既能让使用者明确指定在一个长度为M毫秒的时间片段内,消耗在垃圾收集上的时间不得超过N毫秒。

G1收集器可以实现在基本不牺牲吞吐量的前提下完成低停顿的内存回收,这是由于它能够极力地避免全区域的垃圾收集,之前的收集器进行收集的范围都是整个新生代或老年代,而​G1将整个Java堆(包括新生代、老年代)划分为多个大小固定的独立区域​(Region),并且跟踪这些区域里面的垃圾堆积程度,​在后台维护一个优先列表,每次根据允许的收集时间,优先回收垃圾最多的区域(这就是Garbage First名称的来由)​。​区域划分及有优先级的区域回收,保证了G1收集器在有限的时间内可以获得最高的收集效率。

垃圾收集器_垃圾收集_06