返回首页 JVM 实用参数系列

CMS 收集器

原文连接 本文连接 译者: iDestiny 校对:梁海舰

HotSpot JVM 的并发标记清理收集器 (CMS 收集器) 的主要目标就是:低应用停顿时间。该目标对于大多数交互式应用很重要,比如 web 应用。在我们看一下有关 JVM 的参数之前, 让我们简要回顾 CMS 收集器的操作和使用它时可能出现的主要挑战。

就像吞吐量收集器 (参见本系列的第 6 部分),CMS 收集器处理老年代的对象, 然而其操作要复杂得多。吞吐量收集器总是暂停应用程序线程,并且可能是相当长的一段时间,然而这能够使该算法安全地忽略应用程序。相比之下,CMS 收集器被设计成在大多数时间能与应用程序线程并行执行,仅仅会有一点 (短暂的) 停顿时间。GC 与应用程序并行的缺点就是,可能会出现各种同步和数据不一致的问题。为了实现安全且正确的并发执行,CMS 收集器的 GC 周期被分为了好几个连续的阶段。

CMS 收集器的过程

CMS 收集器的 GC 周期由 6 个阶段组成。其中 4 个阶段 (名字以 Concurrent 开始的) 与实际的应用程序是并发执行的,而其他 2 个阶段需要暂停应用程序线程。

  1. 初始标记:为了收集应用程序的对象引用需要暂停应用程序线程,该阶段完成后,应用程序线程再次启动。
  2. 并发标记:从第一阶段收集到的对象引用开始,遍历所有其他的对象引用。
  3. 并发预清理:改变当运行第二阶段时,由应用程序线程产生的对象引用,以更新第二阶段的结果。
  4. 重标记:由于第三阶段是并发的,对象引用可能会发生进一步改变。因此,应用程序线程会再一次被暂停以更新这些变化,并且在进行实际的清理之前确保一个正确的对象引用视图。这一阶段十分重要,因为必须避免收集到仍被引用的对象。
  5. 并发清理:所有不再被应用的对象将从堆里清除掉。
  6. 并发重置:收集器做一些收尾的工作,以便下一次 GC 周期能有一个干净的状态。

一个常见的误解是, CMS 收集器运行是完全与应用程序并发的。我们已经看到,事实并非如此,即使 “stop-the-world” 阶段相对于并发阶段的时间很短。

应该指出,尽管 CMS 收集器为老年代垃圾回收提供了几乎完全并发的解决方案,然而年轻代仍然通过 “stop-the-world” 方法来进行收集。对于交互式应用,停顿也是可接受的,背后的原理是年轻带的垃圾回收时间通常是相当短的。

挑战

当我们在真实的应用中使用 CMS 收集器时,我们会面临两个主要的挑战,可能需要进行调优:

  1. 堆碎片
  2. 对象分配率高

堆碎片是有可能的,不像吞吐量收集器,CMS 收集器并没有任何碎片整理的机制。因此,应用程序有可能出现这样的情形,即使总的堆大小远没有耗尽,但却不能分配对象——仅仅是因为没有足够连续的空间完全容纳对象。当这种事发生后,并发算法不会帮上任何忙,因此,万不得已 JVM 会触发 Full GC。回想一下,Full GC 将运行吞吐量收集器的算法,从而解决碎片问题——但却暂停了应用程序线程。因此尽管 CMS 收集器带来完全的并发性,但仍然有可能发生长时间的 “stop-the-world” 的风险。这是 “设计”,而不能避免的——我们只能通过调优收集器来它的可能性。想要 100% 保证避免”stop-the-world”,对于交互式应用是有问题的。

第二个挑战就是应用的对象分配率高。如果获取对象实例的频率高于收集器清除堆里死对象的频率,并发算法将再次失败。从某种程度上说,老年代将没有足够的可用空间来容纳一个从年轻代提升过来的对象。这种情况被称为 “并发模式失败”,并且 JVM 会执行堆碎片整理:触发 Full GC。

当这些情形之一出现在实践中时 (经常会出现在生产系统中),经常被证实是老年代有大量不必要的对象。一个可行的办法就是增加年轻代的堆大小,以防止年轻代短生命的对象提前进入老年代。另一个办法就似乎利用分析器,快照运行系统的堆转储,并且分析过度的对象分配,找出这些对象,最终减少这些对象的申请。

下面我看看大多数与 CMS 收集器调优相关的 JVM 标志参数。

-XX:+UseConcMarkSweepGC

该标志首先是激活 CMS 收集器。默认 HotSpot JVM 使用的是并行收集器。

-XX:UseParNewGC

当使用 CMS 收集器时,该标志激活年轻代使用多线程并行执行垃圾回收。这令人很惊讶,我们不能简单在并行收集器中重用 - XX:UserParNewGC 标志,因为概念上年轻代用的算法是一样的。然而,对于 CMS 收集器,年轻代 GC 算法和老年代 GC 算法是不同的,因此年轻代 GC 有两种不同的实现,并且是两个不同的标志。

注意最新的 JVM 版本,当使用 - XX:+UseConcMarkSweepGC 时,-XX:UseParNewGC 会自动开启。因此,如果年轻代的并行 GC 不想开启,可以通过设置 - XX:-UseParNewGC 来关掉。

-XX:+CMSConcurrentMTEnabled

当该标志被启用时,并发的 CMS 阶段将以多线程执行 (因此,多个 GC 线程会与所有的应用程序线程并行工作)。该标志已经默认开启,如果顺序执行更好,这取决于所使用的硬件,多线程执行可以通过 - XX:-CMSConcurremntMTEnabled 禁用。

-XX:ConcGCThreads

标志 - XX:ConcGCThreads=(早期 JVM 版本也叫 -XX:ParallelCMSThreads) 定义并发 CMS 过程运行时的线程数。比如 value=4 意味着 CMS 周期的所有阶段都以 4 个线程来执行。尽管更多的线程会加快并发 CMS 过程,但其也会带来额外的同步开销。因此,对于特定的应用程序,应该通过测试来判断增加 CMS 线程数是否真的能够带来性能的提升。

如果还标志未设置,JVM 会根据并行收集器中的 - XX:ParallelGCThreads 参数的值来计算出默认的并行 CMS 线程数。该公式是 ConcGCThreads = (ParallelGCThreads + 3)/4。因此,对于 CMS 收集器, -XX:ParallelGCThreads标志不仅影响“stop-the-world”垃圾收集阶段,还影响并发阶段。

总之,有不少方法可以配置 CMS 收集器的多线程执行。正是由于这个原因, 建议第一次运行 CMS 收集器时使用其默认设置, 然后如果需要调优再进行测试。只有在生产系统中测量 (或类生产测试系统) 发现应用程序的暂停时间的目标没有达到 , 就可以通过这些标志应该进行 GC 调优。

-XX:CMSInitiatingOccupancyFraction

当堆满之后,并行收集器便开始进行垃圾收集,例如,当没有足够的空间来容纳新分配或提升的对象。对于 CMS 收集器,长时间等待是不可取的,因为在并发垃圾收集期间应用持续在运行 (并且分配对象)。因此,为了在应用程序使用完内存之前完成垃圾收集周期,CMS 收集器要比并行收集器更先启动。

因为不同的应用会有不同对象分配模式,JVM 会收集实际的对象分配 (和释放) 的运行时数据,并且分析这些数据,来决定什么时候启动一次 CMS 垃圾收集周期。为了引导这一过程, JVM 会在一开始执行 CMS 周期前作一些线索查找。该线索由 -XX:CMSInitiatingOccupancyFraction=来设置,该值代表老年代堆空间的使用率。比如,value=75意味着第一次CMS垃圾收集会在老年代被占用75%时被触发。通常CMSInitiatingOccupancyFraction的默认值为68(之前很长时间的经历来决定的)。

-XX:+UseCMSInitiatingOccupancyOnly

我们用 -XX+UseCMSInitiatingOccupancyOnly 标志来命令 JVM 不基于运行时收集的数据来启动 CMS 垃圾收集周期。而是,当该标志被开启时,JVM 通过 CMSInitiatingOccupancyFraction 的值进行每一次 CMS 收集,而不仅仅是第一次。然而,请记住大多数情况下,JVM 比我们自己能作出更好的垃圾收集决策。因此,只有当我们充足的理由 (比如测试) 并且对应用程序产生的对象的生命周期有深刻的认知时,才应该使用该标志。

-XX:+CMSClassUnloadingEnabled

相对于并行收集器,CMS 收集器默认不会对永久代进行垃圾回收。如果希望对永久代进行垃圾回收,可用设置标志 -XX:+CMSClassUnloadingEnabled。在早期 JVM 版本中,要求设置额外的标志 - XX:+CMSPermGenSweepingEnabled。注意,即使没有设置这个标志,一旦永久代耗尽空间也会尝试进行垃圾回收,但是收集不会是并行的,而再一次进行 Full GC。

-XX:+CMSIncrementalMode

该标志将开启 CMS 收集器的增量模式。增量模式经常暂停 CMS 过程,以便对应用程序线程作出完全的让步。因此,收集器将花更长的时间完成整个收集周期。因此,只有通过测试后发现正常 CMS 周期对应用程序线程干扰太大时,才应该使用增量模式。由于现代服务器有足够的处理器来适应并发的垃圾收集,所以这种情况发生得很少。

-XX:+ExplicitGCInvokesConcurrent and -XX:+ExplicitGCInvokesConcurrentAndUnloadsClasses

如今, 被广泛接受的最佳实践是避免显式地调用 GC(所谓的 “系统 GC”),即在应用程序中调用 system.gc()。然而,这个建议是不管使用的 GC 算法的,值得一提的是,当使用 CMS 收集器时,系统 GC 将是一件很不幸的事,因为它默认会触发一次 Full GC。幸运的是,有一种方式可以改变默认设置。标志 - XX:+ExplicitGCInvokesConcurrent 命令 JVM 无论什么时候调用系统 GC,都执行 CMS GC,而不是 Full GC。第二个标志 - XX:+ExplicitGCInvokesConcurrentAndUnloadsClasses 保证当有系统 GC 调用时,永久代也被包括进 CMS 垃圾回收的范围内。因此,通过使用这些标志,我们可以防止出现意料之外的”stop-the-world” 的系统 GC。

-XX:+DisableExplicitGC

然而在这个问题上… 这是一个很好提到 - XX:+ DisableExplicitGC 标志的机会,该标志将告诉 JVM 完全忽略系统的 GC 调用 (不管使用的收集器是什么类型)。对于我而言,该标志属于默认的标志集合中,可以安全地定义在每个 JVM 上运行,而不需要进一步思考。

上一篇: 吞吐量收集器 下一篇: GC 日志