性能文章>JVM 源码解读之 CMS 何时会进行 Full GC>

JVM 源码解读之 CMS 何时会进行 Full GC原创

2年前
861104

前言

本文内容是基于 JDK 8

在文章 JVM 源码解读之 CMS GC 触发条件 中分析了 CMS GC 触发的五类情况,并且提到 CMS GC 分为 foreground collector 和 background collector。
不管是 foreground collector 还是 background collector 使用的都是 mark-sweep 算法,分阶段进行标记清理,优点很明显-低延时,但最大的缺点是存在碎片,内存空间利用率低。因此,CMS 为了解决这个问题,在每次进行 foreground collector 之前,判断是否需要进行一次压缩式 GC。

此压缩式 GC,CMS 使用的是跟 Serial Old GC 一样的 LISP2 算法,其使用 mark-compact 来做 Full GC,一般称之为 MSC(mark-sweep-compact),它收集的范围是 Java 堆的 Young Gen 和 Old Gen 以及 metaspace(元空间)。

本文不涉及具体的收集过程,只分析 CMS 在什么情况下会进行 compact 的 Full GC。

什么情况下会进行一次压缩式 Full GC 呢?

何时会进行 FullGC?

下面这段代码就是 CMS 进行判断是进行 mark-sweep 的 foreground collector,还是进行 mark-sweep-compact 的 Full GC。主要的判断依据就是是否进行压缩,即代码中的 should_compact。

  • // Check if we need to do a compaction, or if not, whether
  • // we need to start the mark-sweep from scratch.
  • bool should_compact = false;
  • bool should_start_over = false;
  • decide_foreground_collection_type(clear_all_soft_refs,
  • &should_compact, &should_start_over);
  • ...
  • if (should_compact) {
  • ...
  • // mark-sweep-compact
  • do_compaction_work(clear_all_soft_refs);
  • ...
  • } else {
  • // mark-sweep
  • do_mark_sweep_work(clear_all_soft_refs, first_state,
  • should_start_over);
  • }
  •  

接下来我们就来分析下在什么情况下会进行 compact,
来看 decideforegroundcollection_type 函数,主要分为 4 种情况:

  1. GC(包含 foreground collector 和 compact 的 Full GC)次数

  2. GCCause 是否是用户请求式触发导致的

  3. 增量 GC 是否可能会失败(悲观策略)

  4. 是否清理所有 SoftReference

  • void CMSCollector::decide_foreground_collection_type(
  • bool clear_all_soft_refs, bool* should_compact,
  • bool* should_start_over) {
  • ...
  •  
  • // 判断是否压缩的逻辑
  •  
  • *should_compact =
  • UseCMSCompactAtFullCollection &&
  • ((_full_gcs_since_conc_gc >= CMSFullGCsBeforeCompaction) ||
  • GCCause::is_user_requested_gc(gch->gc_cause()) ||
  • gch->incremental_collection_will_fail(true /* consult_young */));
  • *should_start_over = false;
  •  
  • if (clear_all_soft_refs && !*should_compact) {
  •  
  • if (CMSCompactWhenClearAllSoftRefs) {
  • *should_compact = true;
  • } else {
  •  
  • if (_collectorState > FinalMarking) {
  • _collectorState = Resetting; // skip to reset to start new cycle
  • reset(false /* == !asynch */);
  • *should_start_over = true;
  • }
  • }
  • }
  • }
  •  

接下来我们具体看每种情况

1. GC(包含 foreground collector 和 compact 的 Full GC)次数

  • // UseCMSCompactAtFullCollection 参数值默认是 true
  • UseCMSCompactAtFullCollection &&
  • ((_full_gcs_since_conc_gc >= CMSFullGCsBeforeCompaction)
  •  

这里说的 GC 次数 fullgcssinceconc_gc,指的是从上次 background collector 后,foreground collector 和 compact 的 Full GC 的次数,只要次数大于等于 CMSFullGCsBeforeCompaction 参数阈值,就表示可以进行一次压缩式的 Full GC。
(CMSFullGCsBeforeCompaction 参数默认是 0,意味着默认是要进行压缩式的 Full GC)

2. GCCause 是否是用户请求式触发导致

  • inline static bool is_user_requested_gc(GCCause::Cause cause) {
  • return (cause == GCCause::_java_lang_system_gc ||
  • cause == GCCause::_jvmti_force_gc);
  • }
  •  

用户请求式触发导致的 GCCause 指的是 javalangsystemgc(即 System.gc())或者 jvmtiforce_gc(即 JVMTI 方式的强制 GC)意味着只要是 System.gc(前提没有配置 ExplicitGCInvokesConcurrent 参数)调用或者 JVMTI 方式的强制 GC 都会进行一次压缩式的 Full GC。

3. 增量 GC 是否可能会失败(悲观策略)

  • bool incremental_collection_will_fail(bool consult_young) {
  • // Assumes a 2-generation system; the first disjunct remembers if an
  • // incremental collection failed, even when we thought (second disjunct)
  • // that it would not.
  • assert(heap()->collector_policy()->is_two_generation_policy(),
  • "the following definition may not be suitable for an n(>2)-generation system");
  • return incremental_collection_failed() ||
  • (consult_young && !get_gen(0)->collection_attempt_is_safe());
  • }
  •  

JVM 源码解读之 CMS GC 触发条件 文章中也提到了这块内容,
指的是两代的 GC 体系中,主要指的是 Young GC 是否会失败。如果 Young GC 已经失败或者可能会失败,CMS 就认为可能存在碎片导致的,需要进行一次压缩式的 Full GC。

“incrementalcollectionfailed()” 这里指的是 Young GC 已经失败,至于为什么会失败一般是因为 Old Gen 没有足够的空间来容纳晋升的对象,比如常见的 “promotion failed” 。

“!getgen(0)->collectionattemptissafe()” 指的是 Young Gen 存活对象晋升是否可能会失败。
通过判断当前 Old Gen 剩余的空间大小是否足够容纳 Young GC 晋升的对象大小。
Young GC 到底要晋升多少是无法提前知道的,因此,这里通过统计平均每次 Young GC 晋升的大小和当前 Young GC 可能晋生的最大大小来进行比较。

下面展示的就是 collectionattemptis_safe 函数的代码:

  • bool DefNewGeneration::collection_attempt_is_safe() {
  • if (!to()->is_empty()) {
  • if (Verbose && PrintGCDetails) {
  • gclog_or_tty->print(" :: to is not empty :: ");
  • }
  • return false;
  • }
  • if (_next_gen == NULL) {
  • GenCollectedHeap* gch = GenCollectedHeap::heap();
  • _next_gen = gch->next_gen(this);
  • }
  • return _next_gen->promotion_attempt_is_safe(used());
  • }
  •  

4. 是否清理所有 SoftReference

  • if (clear_all_soft_refs && !*should_compact) {
  •  
  • if (CMSCompactWhenClearAllSoftRefs) {
  • *should_compact = true;
  • }
  • ...
  •  

SoftReference 软引用,你应该了解它的特性,一般是在内存不够的时候,GC 会回收相关对象内存。这里说的就是需要回收所有软引用的情况,在配置了 CMSCompactWhenClearAllSoftRefs 参数的情况下,会进行一次压缩式的 Full GC。

JDK 1.9 有变更:
彻底去掉了 CMS forground collector 的功能,也就是说除了 background collector,就是压缩式的 Full GC。自然(UseCMSCompactAtFullCollection、CMSFullGCsBeforeCompaction 这两个参数也已经不在支持了。

总结

本文着重介绍了 CMS 在以下 4 种情况:

  • GC(包含 foreground collector 和 compact 的 Full GC)次数

  • GCCause 是否是用户请求式触发导致

  • 增量 GC 是否可能会失败(悲观策略)

  • 是否清理所有 SoftReference

会进行压缩式的 Full GC,并且详细介绍了每种情况下的触发条件。我们在 GC 调优时应该尽可能的避免压缩式的 Full GC,因为其使用的是 Serial Old GC 类似算法,它是单线程对全堆以及 metaspace 进行回收,STW 的时间会特别长,对业务系统的可用性影响比较大。

分类:标签:
请先登录,感受更多精彩内容
快去登录吧,你将获得
  • 浏览更多精彩评论
  • 和开发者讨论交流,共同进步

为你推荐

不起眼,但是足以让你有收获的JVM内存分析案例
分析 这个问题说白了,就是说有些int[]对象不知道是哪里来的,于是我拿他的例子跑了跑,好像还真有这么回事。点该 dump 文件详情,查看相关的 int[] 数组,点该对象的“被引用对象”,发现所
从一起GC血案谈到反射原理
前言 首先回答一下提问者的问题。这主要是由于存在大量反射而产生的临时类加载器和 ASM 临时生成的类,这些类会被保留在 Metaspace,一旦 Metaspace 即将满的时候,就会触发 Fu
关于内存溢出,咱再聊点有意思的?
概述 上篇文章讲了JVM在GC上的一个设计缺陷,揪出一个导致GC慢慢变长的JVM设计缺陷,可能有不少人还是没怎么看明白的,今天准备讲的大家应该都很容易看明白 本文其实很犹豫写不写,因为感觉没有
协助美团kafka团队定位到的一个JVM Crash问题
概述 有挺长一段时间没写技术文章了,正好这两天美团kafka团队有位小伙伴加了我微信,然后咨询了一个JVM crash的问题,大家对crash的问题都比较无奈,因为没有现场,信息量不多,碰到这类问题我
又发现一个导致JVM物理内存消耗大的Bug(已提交Patch)
概述 最近我们公司在帮一个客户查一个JVM的问题(JDK1.8.0_191-b12),发现一个系统老是被OS Kill掉,是内存泄露导致的。在查的过程中,阴差阳错地发现了JVM另外的一个Bug。这个B
JVM实战:优化我的IDEA GC
IDEA是个好东西,可以说是地球上最好的Java开发工具,但是偶尔也会卡顿,仔细想想IDEA也是Java开发的,会不会和GC有关,于是就有了接下来对IDEA的GC进行调优 IDEA默认JVM参数: -
不起眼,但是足以让你收获的JVM内存案例
今天的这个案例我觉得应该会让你涨姿势吧,不管你对JVM有多熟悉,看到这篇文章,应该还是会有点小惊讶的,不过我觉得这个案例我分享出来,是想表达不管多么奇怪的现象请一定要追究下去,会让你慢慢变得强大起来,
如何通过反射获得方法的真实参数名(以及扩展研究)
前段时间,在做一个小的工程时,遇到了需要通过反射获得方法真实参数名的场景,在这里我遇到了一些小小的问题,后来在部门老大的指导下,我解决了这个问题。通过解决这个问题,附带着我了解到了很多新的知识,我觉得