您的位置: 首页  >  文章  >  CMS垃圾回收器细节思考与补充

CMS垃圾回收器细节思考与补充

分类: 文章 • 2024-09-03 19:34:16

CMS垃圾回收器作为jdk6、jdk7、jdk8等jdk版本对老年代进行垃圾回收的首选，其重要性不言而喻。深入理解CMS垃圾回收器的各个阶段存在的价值对于性能调优非常关键。

参考博客3给出了CMS垃圾回收器的7个步骤：
1. 初始标记(CMS-initial-mark) ,会导致swt；
2. 并发标记(CMS-concurrent-mark)，与用户线程同时运行；
3. 预清理（CMS-concurrent-preclean），与用户线程同时运行；
4. 可被终止的预清理（CMS-concurrent-abortable-preclean） 与用户线程同时运行；
5. 重新标记(CMS-remark) ，会导致swt；
6. 并发清除(CMS-concurrent-sweep)，与用户线程同时运行；
7. 并发重置状态等待下次CMS的触发(CMS-concurrent-reset)，与用户线程同时运行。
CMS垃圾回收器细节思考与补充

总的来说，CMS核心目标是缩短stop-the-world的时间，以快速响应业务。为此，CMS采用两次（初始标记和重新标记）短停顿来代替一次长停顿。上述步骤中的1和5即为两次stw，其他步骤则是用户线程和GC线程并发执行。接下来结合参考博客1逐一对上述步骤进行分析：

1、（STW）初始标记：这个阶段是标记从GCRoots直接可达的老年代对象，以及新生代直接引用的老年代对象，就是下图中灰色的点。这个过程是单线程的（JDK7之前单线程，JDK8之后并行，可以通过参数CMSParallelInitialMarkEnabled调整）。

CMS垃圾回收器细节思考与补充

由图可知，初始标记只是标记出了GCRoots直接可达的老年代对象，因而此次停顿时间通常很短。PS：在Java语言里，可作为GC Roots对象的包括如下几种：

  1.  虚拟机线程栈(栈桢中的本地变量表)中的引用的对象 ；
  2. 方法区中的类静态属性引用的对象 ；
  3. 方法区中的常量引用的对象 ；
  4.  本地方法栈中JNI的引用的对象。

2、并发标记：由上一个阶段标记过的对象，开始tracing过程，标记所有可达的对象，这个阶段垃圾回收线程和应用线程同时运行，如上图中的灰色的点。在并发标记过程中，应用线程还在跑，因此会导致有些对象会从新生代晋升到老年代、有些老年代的对象引用会被改变、有些对象会直接分配到老年代，这些受到影响的老年代对象所在的card会被标记为dirty，用于重新标记阶段扫描。这个阶段过程中，老年代对象的card被标记为dirty的可能原因，就是下图中绿色的线：
CMS垃圾回收器细节思考与补充

上图中绿色的线其实对应了四种情况，这四种情况在参考博客2中已经进行了总结：

  1. 新生代对象晋升到老年代
  2. 新生代新创建的对象（Eden区）引用了原先老年代未被标记的对象
  3. 直接在老年代分配的对象
  4. 老年代对象的引用关系发生变化
    为了提高重新标记的效率,该阶段会把上述对象所存在的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的使用空间大于“CMSScheduleRemarkEdenSizeThreshold”，这个参数的默认值是2M；
  • Eden的使用率大于等于“CMSScheduleRemarkEdenPenetration”，这个参数的默认值是50%。

如果不满足上面两个条件，则进入可中断的预清理，可中断预清理可能会执行多次，那么退出这个阶段的出口有两个：

  • 设置了CMSMaxAbortablePrecleanLoops，并且执行的次数超过了这个值，这个参数的默认值是0；

  • CMSMaxAbortablePrecleanTime，执行可中断预清理的时间超过了这个值，这个参数的默认值是5000毫秒。

有可能可中断预清理过程中一直没等到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标记需要扫描的年轻代的对象。

 

参考博客：

1、https://www.jianshu.com/p/78017c8b8e0f 不可错过的CMS学习笔记

2、https://www.codercto.com/a/11419.html  理解GC日志

3、https://blog.****.net/zqz_zqz/article/details/70568819 CMS垃圾回收器详解

4、https://www.jianshu.com/p/08f0b85ad665  CMS垃圾回收器详解

5、http://www.sohu.com/a/214780788_753508  图解 CMS 垃圾回收机制原理

6、https://blog.****.net/Saintyyu/article/details/94125317  Java finalize函数与软引用、弱引用、虚引用

7、https://www.jianshu.com/p/c79c5e02ebe6 JVM源码分析之安全点safepoint

8、https://blog.****.net/Saintyyu/article/details/94125317 Java finalize函数与软引用、弱引用、虚引用

相关推荐