JVM 之垃圾收集器

首先了解两个概念

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

如果说垃圾收集算法是内存回收的方法论,那么垃圾收集器就是内存回收的具体实现。不同厂商不同版本的虚拟机所提供的垃圾收集器都可能有很大的差别,这里谈论的收集器基于JDK 1.7 Update 14之后的HotSpot虚拟机(在这个版本中正式提供了商用的G1收集器,之前的G1仍处于试验状态),这个虚拟机包含的所有收集器如下图所示。

《JVM 之垃圾收集器》

Serial收集器

Serial是一个单线程的收集器,但它的“单线程”意义并不仅仅说明它只会使用一个CPU或一条手机此案成去完成垃圾和收集工作,更重要的是它进行垃圾收集时,必须暂停其他所有的工作线程,直到它收集结束。

虽然很多缺点,但是它依然是虚拟机运行在Client模式下的默认新生代收集器,也有着它的优势:简单高效。

《JVM 之垃圾收集器》

ParNew收集器

ParNew收集器其实就是Serial收集器的多线程版本,除了使用多条线程进行垃圾收集之外,,其余行为包括Serial收集器可用的所有控制参数、手机算法、Stop The World、对象分配规则、回收策略都与Serila收集器完全一样。

它是运行在Server模式下的虚拟机中首选的新生代收集器,其中有一个与性能无关但很重要的原因是:除了Serial收集器外,目前只有它能与CMS收集器配合工作。

《JVM 之垃圾收集器》

Parallel Scavenge收集器

Parallel Scavenge收集器是一个新生代收集器,它也是使用复制算法的收集器,又是并行的多线程收集器。它的特点是它的关注点与其他收集器不同,CMS等收集器的关注点是尽可能地缩短垃圾收集时用户线程的停顿时间,而它的目标是达到一个可控制的吞吐量。所谓吞吐量就是CPU用于运行用户代码的时间与CPU总消耗时间的比值(虚拟机总共运行了100分钟,其中垃圾收集花掉1分钟,那吞吐量就是99%)。也被称为“吞吐量优先”收集器。

Serial Old收集器

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

Parallel Old收集器

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

《JVM 之垃圾收集器》

CMS收集器

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

  • 初始标记(CMS initial mark)
  • 并发标记(CMS concurrent mark)
  • 重新标记(CMS remark)
  • 并发清除(CMS concurrent sweep)

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

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

《JVM 之垃圾收集器》

CMS的优势:并发收集、低停顿。

CMS的缺点:

  • 对CPU资源非常敏感。CMS默认启动的回收线程数是(CPU数量 + 3)/4,并发回收时垃圾收集线程所占CPU资源随着CPU数量的增加而下降,而且在CPU不足4个时,CMS对用户程序的影响就可能变得很大,导致执行速度降低。
  • CMS收集器无法处理浮动垃圾,可能出现“Concurrent Mode Failure”失败而导致另一次Full GC的产生。
  • CMS是一款基于“标记-清除”算法实现的收集器,这意味着收集结束时会有大量空间碎片产生。空间碎片太多的时候,将会给大对象分配带来很大麻烦。

G1收集器

G1是一款面向服务端应用的垃圾收集器。HOtSpot开发团队赋予它的使命是未来可以替换掉CMS收集器。

G1具备如下特点:

  • 并行与并发:G1能充分利用多CPU、多核环境下的硬件优势,使用多个CPU来缩短Stop-The-World停顿的时间,部分其他收集器原本需要停顿Java线程执行的GC动作,G1收集器仍然可以通过并发的方式让Java程序继续执行。
  • 分代收集:虽然G1可以不需要其他收集器配合就能独立管理整个GC堆,但它能够采用不同的方式去处理新创建的对象和已经存活了一段时间、熬过多次GC的就对象以获取更好的收集效果。
  • 空间整合:G1从整体上来看是基于“标记-整理”算法实现的收集器,从局部(两个Region之间)上来看是基于“复制”算法实现的,这意味着G1运作期间不会产生内存空间碎片,收集后能提供规整的可用内存。
  • 可预测的停顿:这是G1相对于CMS的另一大优势。

在G1之前的其他收集器进行收集的范围都是整个新生代或者老年代,而G1不再是这样。使用G1收集器时,Java堆的内存布局就与其他收集器有很大差别,它将整个Java堆划分为多个大小相等的独立区域(Region),虽然还保留有新生代和老年代的概念,但新生代和老年代不再是物理隔离的了,他们都是一部分Region(不需要连续)的集合。

    原文作者:JVM
    原文地址: https://juejin.im/entry/58ccb473b123db0053283905
    本文转自网络文章,转载此文章仅为分享知识,如有侵权,请联系博主进行删除。
点赞