CMS 执行的七个阶段

2021-01-17 14:45:51   最后更新: 2021-01-17 14:45:51   访问数量:232




 

java 优于 c++ 的一个亮点就是自动的垃圾回收机制,成也萧何败萧何,最困扰 java 程序员的问题往往又都和垃圾回收机制有关,作为一个 java 程序员,如果你不了解 java 垃圾回收的机制,那么你时刻都可能面临性能的瓶颈,甚至遇到种种诡异的问题而无从下手。

 

此前,我们已经介绍过 java 垃圾回收相关的很多内容:

 

HotSpot 提供的垃圾收集器

 

本文我们就来详细介绍一个 java 中明星级的垃圾回收器 CMS 的回收机制,而新一代的 G1 回收器的执行机制会在下一篇文章中再来介绍,敬请期待。

 

 

CMS 是 Concurrent Mark Sweep 的缩写,是现在主流十分常用的老年代垃圾回收器,他的主要目标是用最短的回收停顿时间实现老年代的清理,因此,对于强调用户体验的互联网应用来说,CMS 成为了一个首选。

 

那么,CMS 垃圾回收器究竟是怎么工作的呢?

 

CMS 垃圾回收器采用了标记清除算法来实现,关于标记-清除算法,可以参看:

常见 GC 算法思想

 

 

说到“标记-清除”算法,顾名思义,jvm 将整个收集过程划分为了“标记”与“清除”两大步骤来实现。

 

具体到标记流程,jvm 采用了“三色标记法”,就是将不同的对象划分为三大类:

 

  1. 黑色对象 -- 已标记,内部引用已经都被处理
  2. 白色对象 -- 未被标记对象
  3. 灰色对象 -- 已被标记,但内部引用未被处理

 

我们知道,jvm 是通过可达性分析法来实现标记过程的,jvm 从 GC Root 开始,逐步遍历引用树来实现对内存区域内每个对象的标记,可以参看:

 

java 对象存活判定算法

 

 

一般来说,人们通常把 CMS 的执行过程分为四个步骤:

 

  1. 初始标记
  2. 并发标记
  3. 重新标记
  4. 并发清除

 

加上可选的阶段,CMS 回收的过程可以划分为七个步骤,下面我们就来详细介绍:

 

  1. 初始标记
  2. 并发标记
  3. 并发预清理
  4. 可中断的并发预清理
  5. 重新标记
  6. 并发清除
  7. 并发重置

 

 

 

4.1 初始标记

 

如上所述,初始标记最重要的工作就是以 GC-Roots 为起点进行可达性分析,标记出所有当前活跃的也就是被引用的对象。

 

但是,除了被 GC-Root 引用外,老年代中的对象如果仅被年轻代中的对象引用,他也是不能回收的,因此,在上述以 GC-Roots 为起点进行的标记完成后,还需要遍历新生代对象,标记可达的老年代对象。

 

由于上述两个过程仅仅遍历被 GC-Roots 和新生代对象直接引用的老年代对象,执行起来速度会非常快,为了避免在标记过程中对象引用的动态变化,在初始标记阶段,程序需要进行短暂停止,这称为“Stop The World”。

 

jdk8 以后,初始标记支持多线程标记,可以通过 CMSParallelInitialMarkEnabled 参数开启。

 

 

 

4.2 并发标记

 

“并发标记”阶段所谓的“并发”,指的就是用户线程可以与回收线程同步执行,而不需要让用户线程暂停,从而保证了用户线程的执行效率。

 

初始标记的过程中,为了尽量缩短用户线程的暂停时间,所以仅对被 GC-Roots 和新生代对象直接引用的老年代对象进行了标记,所以,接下来的一项工作就是对 GC-Roots 和新生代对象间接引用的老年代对象进行标记,这就是并发标记阶段的主要工作了。

 

4.2.1 如何处理并发标记阶段的引用关系变更

 

由于在并发标记阶段,用户线程与回收线程并发执行,随时可能有新生代的对象晋升到老年代、直接在老年代分配对象或者引用关系发生变更等等情况发生,这些情况下,jvm 是否必须扫描整个老年代才能够识别出这些发生了变化的对象呢?

 

答案当然是否定的,HotSpot 使用了一套名叫“卡表”(Card Table)的数据结构来管理老年代的内存,Card Table 实际上就是一个索引列表,每一个表项占用 1 byte 空间,索引内存中占 512 byte 的页空间。

 

而在对每一个对象引用进行写操作之前和之后 HotSpot 都附加了一定的逻辑,称之为“写屏障”(Write Barrier),写屏障会在一个对象的引用发生变化时,将该对象所在的页在卡表中对应的表项标记为 dirty。

 

但是,由于 jvm 中对象引用变更是极为频繁的,反复读写卡页显然会有很大的性能开销,于是,从 JDK7 开始,HotSpot 引入了一个新的 JVM 参数 -XX:+UseCondCardMark,从而让已经标记过的卡页不再重复标记。

 

 

 

4.3 并发预清理

 

这一步是可选的,可以通过参数 CMSPrecleaningEnabled 参数可以启用或关闭该阶段,默认是开启的。

 

上文已经介绍到,在并发标记阶段,由于引用的变更,可能会产生一些 dirty page,这一阶段的主要工作就就是处理这些脏页,虽然在后面的重新标记阶段也拥有处理脏页的逻辑,但重新标记阶段会 Stop The World,所以这一阶段的核心仍然是让停顿时间尽量缩短。

 

4.4 可中断的并发预清理

 

这一阶段的主要工作是处理新生代指向老年代的新引用,从而让老年代的一些未被标记的对象成为活跃对象。

 

同样,在重新标记阶段也会处理这样的情况,这一阶段仍然是为了缩短停顿时间而进行的。

 

CMS 对于该阶段有以下 4 个参数:

 

  1. CMSScheduleRemarkEdenSizeThreshold -- 当 eden 区空间超过该值时才执行该阶段,默认为 2M
  2. CMSScheduleRemarkEdenPenetration -- 当 eden 空间使用率大于该值时,中断该阶段的执行,默认为 50%
  3. CMSMaxAbortablePrecleanTime -- 该阶段的最长执行时间,默认为 5s
  4. CMSScavengeBeforeRemark -- 强制在该阶段进行一次 minorGC

 

 

 

显然,在这一阶段中要识别新生代对象对老年代对象的新引用,那么就必须扫描整个新生代,这显然是一项很耗时的操作,但由于新生代的对象大多是朝生夕死的,所以如果在一次 minorGC 之后紧接着进行一次预清理,新生代中需要扫描的对象就会所剩无几了。

 

CMS 通过 CMSScavengeBeforeRemark 参数强制在可中断的并发预清理阶段执行一次 minorGC,虽然 minorGC 也会让用户线程短暂停顿,但这样可以缩短下一阶段的停顿时间,整体上还是利大于弊的。

 

4.5 重新标记

 

在上述的并发过程中,用户线程始终在执行,因此随时可能会产生引用变更,比如:

 

  1. 老年代未标记对象被新生代对象引用
  2. 新生代对象晋升到老年代
  3. 已标记对象增加了对未标记对象的引用
  4. 已标记对象的引用被删除

 

 

 

这些情况下,很有可能造成标记数据的不准确,如果直接进行清理,就有可能有误清理的情况发生,因此,jvm 需要再一次 Stop The World 来进行重新标记,从而保证在真正的清理前,标记的准确性。

 

重新标记阶段,jvm 主要进行以下三个工作:

 

  1. 遍历新生代对象,重新标记被引用的老年代对象
  2. 从 GC Roots 出发,重新标记被引用的老年代对象
  3. 遍历卡表,对脏页内的老年代对象进行重新标记

 

但由于有了前面三个步骤的反复标记过程,重新标记阶段的工作量已经被大大降低,停顿时间当然也因此大大减少。

 

4.6 并发清除

 

完成了标记工作,就只剩下最后的一步工作,那就是清除了。

 

由于被清除的对象都是未被使用的对象,因此在清楚操作进行中,是不需要 Stop The World 的,这一步操作也是和用户线程同步执行的。

 

4.7 并发重置

 

完成了整个 CMS 的标记-清除工作后,需要将 CMS 算法的内部数据进行重置,从而让下一次 GC 顺利开始。

 

 

下面是一次 CMS 进行 Full GC 的完整日志,我们可以清楚的看到每一阶段的运行信息与耗时情况:

 

2021-01-17T12:52:41.268+0800: 463.575: Total time for which application threads were stopped: 0.4222317 seconds, Stopping threads took: 0.0001890 seconds

2021-01-17T12:52:41.268+0800: 463.575: Application time: 0.0000643 seconds

// 初始标记(Initial Mark)

2021-01-17T12:52:41.271+0800: 463.578: [GC (CMS Initial Mark) [1 CMS-initial-mark: 1777676K(3145728K)] 1987618K(5033216K), 0.0327958 secs] [Times: user=0.12 sys=0.00, real=0.04 secs]

// 并发标记(Concurrent Mark)

2021-01-17T12:52:41.304+0800: 463.611: [CMS-concurrent-mark-start]

2021-01-17T12:52:42.050+0800: 464.356: [CMS-concurrent-mark: 0.746/0.746 secs] [Times: user=2.61 sys=0.21, real=0.74 secs]

// 并发预清理(Concurrent Preclean)

2021-01-17T12:52:42.050+0800: 464.356: [CMS-concurrent-preclean-start]

2021-01-17T12:52:42.171+0800: 464.477: [CMS-concurrent-preclean: 0.056/0.121 secs] [Times: user=0.47 sys=0.05, real=0.12 secs]

// 并发可取消的预清理(Concurrent Abortable Preclean)

2021-01-17T12:52:42.171+0800: 464.477: [CMS-concurrent-abortable-preclean-start]

2021-01-17T12:52:43.753+0800: 466.059: [CMS-concurrent-abortable-preclean: 1.128/1.582 secs] [Times: user=4.86 sys=0.41, real=1.59 secs]

// 最终标记(Final Remark)

2021-01-17T12:52:43.756+0800: 466.063: [GC (CMS Final Remark) [YG occupancy: 1414648 K (1887488 K)]466.063: [Rescan (parallel) , 0.2583497 secs]466.321:[weak refs processing, 0.0005512 secs]466.322: [class unloading, 0.0514608 secs]466.373: [scrub symbol table, 0.0122328 secs]466.385: \[scrub string table, 0.0017416 secs][1 CMS-remark: 1974197K(3145728K)] 3388846K(5033216K), 0.3265593 secs] [Times: user=0.83 sys=0.00, real=0.33 secs]

// 并发清除(Concurrent Sweep)

2021-01-17T12:52:44.083+0800: 466.389: [CMS-concurrent-sweep-start]

2021-01-17T12:52:48.578+0800: 470.885: [CMS-concurrent-sweep: 3.224/4.495 secs] [Times: user=14.43 sys=1.19, real=4.49 secs]

// 并发重置(Concurrent Reset)

2021-01-17T12:52:48.638+0800: 470.945: [CMS-concurrent-reset-start]

2021-01-17T12:52:48.647+0800: 470.953: [CMS-concurrent-reset: 0.008/0.008 secs] [Times: user=0.06 sys=0.01, real=0.01 secs]

 

 

欢迎关注微信公众号,以技术为主,涉及历史、人文等多领域的学习与感悟,每周三到七篇推文,全部原创,只有干货没有鸡汤

 

 

 

 

java 专题






技术帖      java      gc      垃圾回收      cms      full gc     


京ICP备2021035038号