CMS垃圾回收器作为jdk6、jdk7、jdk8等jdk版本对老年代进行垃圾回收的首选,其重要性不言而喻。深入理解CMS垃圾回收器的各个阶段存在的价值对于性能调优非常关键。
参考博客3给出了CMS垃圾回收器的7个步骤: 1. 初始标记(CMS-initial-mark) ,会导致stw; 2. 并发标记(CMS-concurrent-mark),与用户线程同时运行; 3. 预清理(CMS-concurrent-preclean),与用户线程同时运行; 4. 可被终止的预清理(CMS-concurrent-abortable-preclean) 与用户线程同时运行; 5. 重新标记(CMS-remark) ,会导致stw; 6. 并发清除(CMS-concurrent-sweep),与用户线程同时运行; 7. 并发重置状态等待下次CMS的触发(CMS-concurrent-reset),与用户线程同时运行。
总的来说,CMS核心目标是缩短stop-the-world的时间,以快速响应业务。为此,CMS采用两次(初始标记和重新标记)短停顿来代替一次长停顿。上述步骤中的1和5即为两次stw,其他步骤则是用户线程和GC线程并发执行。接下来结合参考博客1逐一对上述步骤进行分析:
1、(STW)初始标记:这个阶段是标记从GCRoots直接可达的老年代对象,以及新生代直接引用的老年代对象,就是下图中灰色的点。这个过程是单线程的(JDK7之前单线程,JDK8之后并行,可以通过参数CMSParallelInitialMarkEnabled调整)。
由图可知,初始标记只是标记出了GCRoots直接可达的老年代对象,因而此次停顿时间通常很短。PS:在Java语言里,可作为GC Roots对象的包括如下几种:
2、并发标记:由上一个阶段标记过的对象,开始tracing过程,标记所有可达的对象,这个阶段垃圾回收线程和应用线程同时运行,如上图中的灰色的点。在并发标记过程中,应用线程还在跑,因此会导致有些对象会从新生代晋升到老年代、有些老年代的对象引用会被改变、有些对象会直接分配到老年代,这些受到影响的老年代对象所在的card会被标记为dirty,用于重新标记阶段扫描。这个阶段过程中,老年代对象的card被标记为dirty的可能原因,就是下图中绿色的线:
上图中绿色的线其实对应了四种情况,这四种情况在参考博客2中已经进行了总结:
为了提高重新标记的效率,该阶段会把上述对象所存在的card标记为dirty,后续只需要扫描dirty card对应的对象。
其中情况1、3、4都非常容易理解,但不知道读者对于情况2是如何理解的呢?情况2对应的就是上图中被标记的Eden区的对象1指向老年代的2。试想一下,在经过初始标记(stw)之后,老年代的2既不是GCRoots直接可达,也不是新生代直接引用的对象,那么在并发标记期间,引用了对象1的那个线程(取名为:线程A)是如何获取到对象2的引用并赋值给对象1的呢?前面已经介绍过了,GC Roots包括了线程栈中引用的对象,如果线程A保存了对象2的引用,那么对象2就应该在初始标记时被标记出来,但现在的情况是对象2在初始标记时没有被标记为可达。
这个疑惑也困扰了我很久,尝试从各种博客或者介绍JVM虚拟机的书籍中寻找答案,最终都无功而返。一种可能的猜测是:线程A在初始标记前直接引用了老年代的对象3(图中未给出示意),而对象3又引用了图中的对象2。那么在初始标记之后,对象3被标记为直接可达,而对象2未被标记。在并发标记期间,线程A在Eden区新创建了一个对象1,然后对象3将对象2赋值给对象1,接着对象3取消了对于对象2的引用。在这样的情形下,我们可以说新生代新创建的对象引用了原先老年代未被标记的对象。
PS:图中还有一个连线被打了个叉,表示在并发标记期间,新生代取消了对老年代对象的引用。对于这样的对象,垃圾回收器可能有两种选择:第一,取消对老年代对象的标记;第二,仍然认为该对象可达,在本轮垃圾回收过程中不被回收,而是在下一轮垃圾回收时再确定是否回收。由于有可能不止一个年轻代的对象引用该老年代对象,不能因为单个引用取消就直接将老年代对象的标记取消,因而个人猜测垃圾回收器会采取方案二。
3、预清理:预清理,也是用于标记老年代存活的对象,目的是为了让重新标记阶段的STW尽可能短。这个阶段的目标是在并发标记阶段被应用线程影响到的老年代对象,包括:(1)老年代中card为dirty的对象;(2)幸存区(from和to)中引用的老年代对象引用的老年代对象。因此,这个阶段也需要扫描新生代+老年代。此外,参考博文1中还提到“根据源码猜测不会扫描Eden区的对象”。对此,我们来分析其合理性。由前面的猜测可知,在初始标记之后,Eden区新创建的对象在并发标记期间引用老年代未被标记过的对象的概率是非常小的。此外,由后面的介绍可知,在重新标记阶段,还会再次对Eden区进行扫描,因而预清理阶段对Eden区进行扫描不仅费时,且收益微乎其微。
4、可中断的预清理:这个阶段的目标跟“预清理”阶段相同,也是为了减轻重新标记阶段的工作量。可中断预清理的价值有二:其一,在进入重新标记阶段之前尽量等到一个Minor GC,以缩短重新标记阶段的停顿时间(stw);其二,默认的可中断预清理会在Eden达到50%的时候开始,这时候离下一次minor gc还有半程的时间,这就可以避免避免短时间内连着的两个停顿(stw)。
在预清理步骤后,如果满足下面两个条件的任意一个,就不会开启可中断的预清理,而直接进入重新标记阶段:
这两个参数的含义是:预清理后,eden空间使用超过2M时才启动可中断的并发预清理(CMS-concurrent-abortable-preclean),低于2M则没有执行的必要,直到eden空间使用率达到50%时则中断“可中断的预清理”阶段,进入重新标记remark阶段。
如果上面两个条件都不满足,则进入可中断的预清理,可中断预清理可能会执行多次,那么退出这个阶段的出口有两个:
有可能可中断预清理过程中一直没等到Minor gc,这时候进入重新标记阶段的话,新生代还有很多活着的对象,就回导致STW变长,因此CMS还提供了CMSScavengeBeforeRemark参数,可以在进入重新标记之前强制进行一次Minor gc。
5、(STW)重新标记(并发):重新扫描堆中的对象,进行可达性分析,标记活着的对象。这个阶段扫描的目标是:新生代的对象 + GC Roots + 前面被标记为dirty的card对应的老年代对象。如果预清理的工作没做好,这一步扫描新生代的时候就会花很多时间,导致这个阶段的停顿时间过长。
这里需要补充一下,为什么说预清理工作能减少重新标记的停顿时间:重新扫描新生代对象和GC Roots对象时,只需要关心其直接引用的老年代对象还没有被标记过的对象(及其子对象),而无须关心已经被标记的直接引用对象:因为已经被标记过的对象如果其对应的card不为dirty,则无须扫描;而已经被标记为dirty card的对象自然会被扫描。因而预清理确实可以缩短重新标记的停顿时长。
6、并发清除:用户线程被重新激活,同时清除那些未被标记为存活的对象。由于CMS并发清理阶段用户线程还在运行着,伴随程序运行自然又会有新的垃圾不断产生,这一部分垃圾出现在标记过程之后,CMS无法在当次收集中处理掉它们,只好留待下一次GC时再清理掉。这一部分垃圾也称为“浮动垃圾”。
到此可知,虚拟机还需要存储一些特殊的信息,以区分出在标记周期以外新产生的对象(未标记)和在标记周期内产生的没有被标记的垃圾对象。
7、并发重置:CMS内部重置回收器状态,准备进入下一个并发回收周期。
小结:CMS的核心思路是,先用一次stw标记新生代和GC Roots直接引用的老年代对象,因而停顿时间通常很短;对于间接引用的对象,则通过并发标记来完成,以减少GC对业务的影响;由于并发标记会导致初始标记的直接引用对象发生变化,因而需要预清理来处理并发标记引起的并发问题;而由于预清理也是并发的,因而最终还需要第二次stw来重新标记并发标记和预处理标记期间的并发问题;而为了缩短第二次stw标记的停顿时间,又增加了可中断的预清理阶段,并期待在该阶段发生一次Minor GC,从而极大地减少了第二次stw标记需要扫描的年轻代的对象。
上面描述的是CMS的并发周期正常完成的情况,但是还有几种CMS并发周期失败的情况(会触发FullGC):
1、执行Minor GC时,如果有老年代引用年轻代对象怎么办?
有研究表明,在所有的引用中,老年代引用新生代这种场景不足1%。
CMS将老年代的空间分成大小为512bytes的块,card table中的每个元素对应着一个块。
并发标记时,如果某个对象的引用发生了变化,就标记该对象所在的块为 dirty card。并发预清理阶段就会重新扫描该块,将该对象引用的对象标识为可达。
当有老年代引用新生代,对应的card table被标识为相应的值(card table中是一个byte,有八位,约定好每一位的含义就可区分哪个是引用新生代,哪个是并发标记阶段修改过的。所以,Minor GC通过扫描card table就可以很快的识别老年代引用新生代。
2、CMS的并发收集周期合适触发?
3、Minor GC会发生stop the world现象吗?
目前所有的新生代gc都是需要STW的,不过由于Minor GC只需要收集年轻代,所以一般只有几十毫秒的停顿,可以忽略不计:
Serial串行收集器
ParNew(并行GC)收集器
参考博客:
1、不可错过的CMS学习笔记 - 知乎 不可错过的CMS学习笔记
2、理解GC日志 | 码农网 理解GC日志
3、CMS垃圾回收器详解_zqz_zqz的博客-CSDN博客_cms垃圾回收器 CMS垃圾回收器详解
4、https://www.jianshu.com/p/08f0b85ad665 CMS垃圾回收器详解 老年代引用新生代
5、图解 CMS 垃圾回收机制原理,面试必知必会 ! 图解 CMS 垃圾回收机制原理
6、Java finalize函数与软引用、弱引用、虚引用_Saintyyu的博客-CSDN博客 Java finalize函数与软引用、弱引用、虚引用
7、JVM源码分析之安全点safepoint - 简书 JVM源码分析之安全点safepoint
8、Java finalize函数与软引用、弱引用、虚引用_Saintyyu的博客-CSDN博客 Java finalize函数与软引用、弱引用、虚引用
9、JVM知识整理 - 简书 JVM知识整理 非常全面
10、G1垃圾收集器入门-原创译文 - OldTrafford - 博客园 G1垃圾收集器入门-译文
11、 JVM中的垃圾回收策略 - 大唐札记 JVM中的垃圾回收策略
12、 Java垃圾回收浅谈_wtopps的专栏-CSDN博客 Java垃圾回收浅谈
13、GC后,内存地址变了,对象引用变了吗? - 你看到过我的小熊吗? - OSCHINA - 中文开源技术交流社区 GC后,内存地址变了,对象引用变了吗?
14、不会还有人以为cms回收器只有4个阶段吧 - 知乎 不会还有人以为cms回收器只有4个阶段吧
15、CMS收集器几个参数详解 -XX:CMSInitiatingOccupancyFraction, CMSFullGCsBeforeCompaction_刘本龙的专栏-CSDN博客 CMS收集器几个参数详解 -XX:CMSInitiatingOccupancyFraction, CMSFullGCsBeforeCompaction
16、Minor GC、Major GC、Full GC、分配担保 - 反光的小鱼儿 - 博客园 Minor GC、Major GC、Full GC、分配担保
17、minor gc 会发生stop the world 现象吗? - 知乎 minor gc 会发生stop the world 现象吗