JVM基础(8)——CMS垃圾回收器

这篇具有很好参考价值的文章主要介绍了JVM基础(8)——CMS垃圾回收器。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

作者简介:大家好,我是smart哥,前中兴通讯、美团架构师,现某互联网公司CTO

联系qq:184480602,加我进群,大家一起学习,一起进步,一起对抗互联网寒冬

学习必须往深处挖,挖的越深,基础越扎实!

阶段1、深入多线程

阶段2、深入多线程设计模式

阶段3、深入juc源码解析

阶段4、深入jdk其余源码解析

阶段5、深入jvm源码解析

一、简介

理想情况下,我们都希望自己的系统能在每次Minor GC后,存活对象都能转移到Survivor区,避免进入老年代。但真实情况是,线上系统很可能因为各种各样的情况,导致很多对象进入老年代,甚至频繁触发老年代的Full GC。所以,我们必须对老年代的垃圾回收器的执行原理有一个清晰的认识,才能在出现问题时及时应对。

二、CMS基本原理

老年代的垃圾回收,我们一般会选择CMS垃圾回收器,它采用的是 标记清除(mark-sweep) 算法。关于标记清除算法,我们已经在JVM垃圾回收算法一文中详细介绍过了标记清除算法,标记清除与标记整理的区别就是它标记完垃圾对象后直接清理掉,这个会造成内存碎片过多的问题,后面会讲到。

针对老年代进行垃圾回收时,CMS也会出现”Stop the World“现象,之前的文章也说过,如果挂起一切工作线程,然后慢慢地去执行”mark-sweep“算法,会导致系统”卡顿“时间过长,很多响应无法处理。CMS采取的策略是: 垃圾回收线程和系统工作线程尽量并行执行 。

CMS在执行一次垃圾回收的过程一共为4个阶段:

  • 初始标记
  • 并发标记
  • 重新标记
  • 并发清理

下面我们来对每一阶段进行分析。

2.1 初始标记

CMS进行垃圾回收时,首先会执行初始标记,这个阶段会让系统的工作线程全部挂起,进入“Stop the World”状态,初始标记,就是标记“GC Roots”能够引用到的对象。如下图:

JVM基础(8)——CMS垃圾回收器,jvm专题,jvm

我们还是以示例代码来看下整个过程:

    public class Kafka {
        public static ReplicaManager replicaManager = new ReplicaManager();
    }
    public class ReplicaManager {
        public ReplicaFetcher replicaFetcher = new ReplicaFetcher();
    }

假设上面代码对应的JVM内存结构如下图:

JVM基础(8)——CMS垃圾回收器,jvm专题,jvm

那么初始标记时,静态变量replicaManager所引用的ReplicaManager对象就会被标记出来,但ReplicaFetcher对象不会被标记,因为类的静态字段和方法的局部变量可以作为“GC Roots”,而类的普通实例字段不能。

初始标记阶段,虽然会出现“Stop the World”,但其实影响不大,因为从“GC Roots”去标记存活对象的效率很高。另外, 可以通过设置参数-XX:+CMSParallelInitialMarkEnabled开始多线程的初始标记,减少STW时间,以提升性能。

2.2 并发标记

接着,进入并发标记阶段,该阶段系统的工作线程可以随时创建各种对象。与此同时,垃圾回收线程会尽可能的对已有的对象进行GC Roots追踪。

所谓GC Roots追踪,就是对老年代里的ReplicaFetcher这类对象,看看被谁引用了?比如ReplicaFetcher对象被ReplicaManager对象的replicaFetcher字段引用,而ReplicaManager对象又被Kafka类的静态字段replicaManager引用。

那么此时,CMS就会认为ReplicaFetcher这个对象其实是被GC Roots间接引用的,所以不需要回收它,可以把它标记存活,如下图:

JVM基础(8)——CMS垃圾回收器,jvm专题,jvm

但是在并发标记的过程中,由于系统在不停的工作,可能会创建出来新的对象,也可能一些旧的对象失去引用,如下图:

JVM基础(8)——CMS垃圾回收器,jvm专题,jvm

并发标记的时候,需要对GC Roots进行深度追踪,看所有对象里到底有多少是存活的,而老年代中的对象存活率又比较高,所以这个过程会追踪大量的对象,比较耗时。

并发标记阶段,其本质就是追踪老年代中的所有对象能否直接或间接被GC Roots引用,这个过程是跟垃圾回收线程并行进行的,所以虽然很耗时,但不会对系统运行造成较大影响。

2.3 重新标记

在第二阶段,一边是GC线程标记着存活对象和垃圾对象,另一边是工作线程不停的创建新对象和让老对象失去引用,所以当第二阶段结束后,会有很多存活对象和垃圾对象是没有被标记出来的:

JVM基础(8)——CMS垃圾回收器,jvm专题,jvm

所以,重新标记阶段的工作,就是让系统停下来,进入“Stop the World”,然后再重新标记一下第二阶段里新创建和新失去引用的那些对象:

JVM基础(8)——CMS垃圾回收器,jvm专题,jvm

重新标记阶段,虽然会发生“Stop the World”,但速度是很快的,因为只是对第二阶段中因为并行而变动过的少数对象进行标记。另外,可以通过设置参数-XX:+CMSScavengeBeforeMark,让重新标记之前尽量先先执行一次Young GC,那么重新标记的时候就可以少扫描一些对象,以提升该阶段的性能。

2.4 并发清理

重新标记完成后,就会恢复工作线程,进入最后的并发清理阶段。该阶段垃圾回收线程和工作线程是并行运行的,垃圾回收线程会清理之前标记为垃圾的对象:

JVM基础(8)——CMS垃圾回收器,jvm专题,jvm

并发清理需要将垃圾对象从各种随机的内存位置清理掉,所以也比较耗时。

并发清理阶段和并发标记阶段一样,是比较耗时的,但是不会挂起工作线程,所以基本不影响系统的运行。

三、性能问题

CMS为了避免长时间的”Stop the World“,采用了4个阶段进行垃圾回收,其中初始标记和重新标记阶段虽然会”Stop the World“,但是耗时很短,所以影响不大;并发标记和并发清理阶段虽然耗时较长,但是可以跟工作线程并行执行,所以影响也不大。

那么,CMS就很完美了吗?显示不是,我们来看下CMS的这种垃圾回收方式可能会出现什么样的问题。

3.1 CPU消耗

CMS垃圾回收器有一个最大的问题,就是并发标记和并发清理阶段,工作线程和垃圾回收线程同时运行,而这两个阶段又比较耗时,所以会导致有限的CPU资源长时间被垃圾回收线程占用。

CMS启动时默认的垃圾回收线程数量是:(CPU核数+3)/4。假设我们用最普通的机器(2核4G)来测算,(2+3)/4=1,也就是说GC线程会占去一个CPU。

3.2 Concurrent Mode Failure

CMS垃圾回收器的另一个问题就是Concurrent Mode Failure。所谓 Concurrent Mode Failure,就是指在并发清理阶段,有一些原来是新生代的对象将晋升到老年代,而此时老年代的可用空间又不够了,就会发生Concurrent Mode Failure。我们来看下整个过程:

首先,在并发清理阶段,由于工作线程也在并行运行,一些新生代对象晋升到了老年代,随后失去了引用,那这些对象就变成了老年代的” 浮动垃圾 “,因为它们已经错过了并发标记,只能等到下一次GC时被回收:

JVM基础(8)——CMS垃圾回收器,jvm专题,jvm

上图中的红圈部分就是一个浮动垃圾。为了应对出现”浮动垃圾“这种情况,CMS会在老年代预留一定的空间,如果CMS在垃圾清理期间,出现了浮动垃圾,且垃圾大小大于老年代中的预留空间,就会出现Concurrent Mode Failure

当出现Concurrent Mode Failure时,CMS会自动让Serial Old垃圾收集器来替代自己,强行进行“Stop the World”,并重新进行GC Roots追踪,标记垃圾对象并清除,完事后才恢复工作线程运行。

综上,生产环境下,这个自动触发CMS垃圾回收的比例需要合理优化下,避免出现Concurrent Mode Failure问题。

CMS触发垃圾回收的时机,其中一个就是当老年代内存占用达到一定的比例,通过 -XX:CMSInitiatingOccupancyFaction参数可以设置这个比例,JDK1.6中默认是92%。

3.3 内存碎片

由于CMS采用标记整理算法对老年代的垃圾对象进行回收,所以会产生大量的内存碎片。如果内存碎片太多,会导致后续对象进入老年代找不到可用的连续空间,触发Full GC。

CMS有一个参数-XX:+UseCMSCompactAtFullCollection(默认打开),表示是否要在Full GC之后进行Stop the World,停止工作线程,然后进行老年代的内存碎片整理。

还有另外一个参数-XX:CMSFullGCsBeforeCompaction,意思是执行多少次Full GC之后再执行一次内存碎片整理工作,默认是0,即每次Full GC之后都会进行一次内存碎片整理。

四、总结

通过上述对CMS垃圾回收器的执行流程分析,我们其实已经知道CMS专门针对“Stop the World”进行了优化:

  • 最耗时的两个阶段——并发标记和并发清理,其实都不需要挂起工作线程,所以对系统整体性能影响不大;
  • 两个需要”Stop the World“的阶段——初始标记和重新标记,仅仅是简单的标记而已,速度非常快,所以基本上对系统的整体性能影响也不大。

但是,用CMS进行老年代的垃圾回收还是要比新生代的Minor GC慢十倍以上,原因很简单:

  • 新生代执行速度快,是因为新生代的存活对象很少,从GC Roots出发马上能追踪到哪些对象是活的,压根不需要追踪多少对象;
  • 老年代中对象的存活率很高,所以并发标记阶段很慢,此外并发清理阶段是去找各种零零散散的垃圾对象,速度也很慢,最后Full GC完还得内存整理,所以非常耗时。

我们这里对 Full GC的所有情况 做一个总结:

  1. 老年代的可用连续内存空间 < 新生代全部对象的大小,且未开启空间担保;
  2. 老年代的可用连续内存空间 < 新生代全部对象的大小,且开启了空间担保,但是老年代的可用连续内存空间<历代晋升到老年代的平均对象大小;
  3. 新生代Minor GC后,存活对象大小 > Survivor大小,而老年代的可用连续内存空间不足;
  4. 老年代已经使用的内存空间超过了-XX:CMSInitiatingOccupancyFaction参数指定的比例。

最后,CMS也存在一些问题,比如CPU消耗、Concurrent Mode Failure、内存碎片等,需要通过一些参数进行合理配置,我们后面章节会通过案例进行讲解如何优化。文章来源地址https://www.toymoban.com/news/detail-794880.html

到了这里,关于JVM基础(8)——CMS垃圾回收器的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • JVM之垃圾回收器

    垃圾回收常见面试题: 如何判断对象是否死亡。 简单的介绍一下强引用、软引用、弱引用、虚引用。虚引用与软引用和弱引用的区别、使用软引用能带来的好处 如何判断一个常量是废弃常量 如何判断一个类是无用的类 垃圾收集有哪些算法,各自的特点? HotSpot 为什么要分

    2024年02月14日
    浏览(43)
  • JVM常见的垃圾回收器(详细)

    1、Young为年轻代出发的垃圾回收器。 2、Old为老触发的垃圾回收器。 3、连线代表的是垃圾回收器的组合。CMS 和Serial Old连线代表CMS一旦不行了,Serial Old上场。 1、什么是STW? STW是Stop-The-World缩写: 是在垃圾回收算法执⾏过程当中,将JVM内存冻结丶应用程序停顿的⼀种状态。

    2024年02月08日
    浏览(35)
  • JVM垃圾回收器G1详解

    在我们应用程序所应对的业务越来越庞大、复杂,用户越来越多,没有GC就不能保证应用程序正常进行,而经常造成STW的GC又跟不上实际的需求,我们需要不断地尝试对GC进行优化。G1(Garbage-First)垃圾回收器是在Java7 update4之后引入的一个新的垃圾回收器,是当今收集器技术发

    2024年02月09日
    浏览(37)
  • 说一下 JVM 有哪些垃圾回收器?

    如果说垃圾收集算法是内存回收的方法论,那么垃圾收集器就是内存回收的具体实现。下图展示了7种作用于不同分代的收集器,其中用于回收新生代的收集器包括Serial、ParNew、Parallel Scavenge,回收老年代的收集器包括SerialOld、Parallel Old、CMS,还有用于回收整个Java堆的G1收集器

    2024年02月22日
    浏览(41)
  • Java虚拟机(JVM)、垃圾回收器

    JRE(Java Runtime Environment,运行环境) 所有的程序都要在JRE下才能够运行。包括JVM和Java核心类库和支持文件。 JDK(Java Development Kit,开发工具包) 用来编译、调试Java程序的开发工具包。包括Java工具(javac/java/jdb等)和Java基础的类库(java API )。 JVM(Java Virtual Machine,虚拟机) JRE的一部分,

    2024年02月12日
    浏览(49)
  • JVM — JDK11垃圾回收器 ZGC

    1. ZGC介绍 ZGC(The Z Garbage Collector)是 JDK 11 中推出的一款低延迟垃圾回收器,为实现以下几个目标而诞生的垃圾回收器,停顿时间不超过 10ms,停顿时间不会因堆变大而变长,支持 8MB~4TB 级别的堆(未来支持 16TB) 2. ZGC内存和原理 2.1 ZGC内存分布 ZGC 与传统的 CMS、G1 不同、它没

    2024年02月13日
    浏览(42)
  • JVM的组件、自动垃圾回收的工作原理、分代垃圾回收过程、可用的垃圾回收器类型

    https://www.processon.com/diagraming/64c8aa11c07d99075d934311 https://www.oracle.com/webfolder/technetwork/tutorials/obe/java/gc01/index.html 年轻代是所有新对象被分配和老化的地方。当年轻代填满时,这会导致minor garbage collection,minor gc会回收掉很多的游离对象。游离的年轻代很快就被收集起来。一些幸存的

    2024年02月14日
    浏览(48)
  • java八股文面试[JVM]——垃圾回收器

    jvm结构总结   常见的垃圾回收器有哪些?     CMS(Concurrent Mark Sweep) 整堆收集器 : G1 由于整个过程中 耗时最长 的 并发标记 和 并发清除 过程中,收集器线程都可以与用户线程一起工作,所以 总体上来说 ,CMS收集器的内存回收过程是与用户线程一起并发地执行。老年代收

    2024年02月11日
    浏览(47)
  • 【jvm系列-10】深入理解jvm垃圾回收器的种类以及内部的执行原理

    JVM系列整体栏目 内容 链接地址 【一】初识虚拟机与java虚拟机 https://blog.csdn.net/zhenghuishengq/article/details/129544460 【二】jvm的类加载子系统以及jclasslib的基本使用 https://blog.csdn.net/zhenghuishengq/article/details/129610963 【三】运行时私有区域之虚拟机栈、程序计数器、本地方法栈 https

    2024年02月05日
    浏览(90)
  • JVM | 垃圾回收器(GC)- Java内存管理的守护者

    在编程世界中, 有效的内存管理 是至关重要的。这不仅确保了应用程序的稳定运行,还可以大大提高性能和响应速度。作为世界上最受欢迎的编程语言之一,通过Java虚拟机内部的垃圾回收器组件来自动管理内存,是成为之一的其中一项必不可少的技术点。 在许多传统的编程

    2024年02月09日
    浏览(53)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包