文章目录

  • CMS收集器
    • CMS的缺点
  • 三色标记算法
    • 漏标
    • 错标
    • 原始快照和增量更新
    • 写屏障
  • 尾巴

CMS（Concurrent Mark Sweep）是一款里程碑式的垃圾收集器，为什么这么说呢？因为在它之前，GC线程和用户线程是无法同时工作的，即使是Parallel Scavenge，也不过是GC时开启多个线程并行回收而已，GC的整个过程依然要暂停用户线程，即Stop The World。这带来的后果就是Java程序运行一段时间就会卡顿一会，降低应用的响应速度，这对于运行在服务端的程序是不能被接收的。

GC时为什么要暂停用户线程？
首先，如果不暂停用户线程，就意味着期间会不断有垃圾产生，永远也清理不干净。
其次，用户线程的运行必然会导致对象的引用关系发生改变，这就会导致两种情况：漏标和错标。

  1. 漏标
    原本不是垃圾，但是GC的过程中，用户线程将其引用关系修改，导致GC Roots不可达，成为了垃圾。这种情况还好一点，无非就是产生了一些浮动垃圾，下次GC再清理就好了。
  2. 错标
    原本是垃圾，但是GC的过程中，用户线程将引用重新指向了它，这时如果GC一旦将其回收，将会导致程序运行错误。

针对这些问题，CMS是如何解决的呢？它是如何做到GC线程和用户线程并发工作的呢？？？

CMS收集器

Concurrent Mark Sweep，从名字上就可以看出来，这是一款采用「标记清除」算法的垃圾收集器，它运行的示意图大概如下：

大概可分为四个主要步骤：

1、初始标记
初始标记仅仅只是标记一下GC Roots能直接关联到的对象，速度很快。初始标记的过程是需要触发STW的，不过这个过程非常快，而且初试标记的耗时不会因为堆空间的变大而变慢，是可控的，因此可以忽略这个过程导致的短暂停顿。

2、并发标记
并发标记就是将初始标记的对象进行深度遍历，以这些对象为根，遍历整个对象图，这个过程耗时较长，而且标记的时间会随着堆空间的变大而变长。不过好在这个过程是不会触发STW的，用户线程仍然可以工作，程序依然可以响应，只是程序的性能会受到一点影响。因为GC线程会占用一定的CPU和系统资源，对处理器比较敏感。CMS默认开启的GC线程数是：(CPU核心数+3)/4，当CPU核心数超过4个时，GC线程会占用不到25%的CPU资源，如果CPU数不足4个，GC线程对程序的影响就会非常大，导致程序的性能大幅降低。

3、重新标记
由于并发标记时，用户线程仍在运行，这意味着并发标记期间，用户线程有可能改变了对象间的引用关系，可能会发生两种情况：一种是原本不能被回收的对象，现在可以被回收了，另一种是原本可以被回收的对象，现在不能被回收了。针对这两种情况，CMS需要暂停用户线程，进行一次重新标记。

4、并发清理
重新标记完成后，就可以并发清理了。这个过程耗时也比较长，且清理的开销会随着堆空间的变大而变大。不过好在这个过程也是不需要STW的，用户线程依然可以正常运行，程序不会卡顿，不过和并发标记一样，清理时GC线程依然要占用一定的CPU和系统资源，会导致程序的性能降低。

CMS的缺点

尽管CMS是一款里程碑式的垃圾收集器，开启了GC线程和用户线程同时工作的先河，但是不管是哪个JDK版本，CMS从来都不是默认的垃圾收集器，究其原因，还是因为CMS不太完美，存在一些缺点。

1、对处理器敏感
并发标记、并发清理阶段，虽然CMS不会触发STW，但是标记和清理需要GC线程介入处理，GC线程会占用一定的CPU资源，进而导致程序的性能下降，程序响应速度变慢。CPU核心数多的话还稍微好一点，CPU资源紧张的情况下，GC线程对程序的性能影响非常大。

2、浮动垃圾
并发清理阶段，由于用户线程仍在运行，在此期间用户线程制造的垃圾就被称为“浮动垃圾”，浮动垃圾本次GC无法清理，只能留到下次GC时再清理。

3、并发失败
由于浮动垃圾的存在，因此CMS必须预留一部分空间来装载这些新产生的垃圾。CMS不能像Serial Old收集器那样，等到Old区填满了再来清理。在JDK5时，CMS会在老年代使用了68%的空间时激活，预留了32%的空间来装载浮动垃圾，这是一个比较偏保守的配置。如果实际引用中，老年代增长的不是太快，可以通过-XX：CMSInitiatingOccupancyFraction参数适当调高这个值。到了JDK6，触发的阈值就被提升至92%，只预留了8%的空间来装载浮动垃圾。
如果CMS预留的内存无法容纳浮动垃圾，那么就会导致「并发失败」，这时JVM不得不触发预备方案，启用Serial Old收集器来回收Old区，这时停顿时间就变得更长了。

4、内存碎片
由于CMS采用的是「标记清除」算法，这就意味这清理完成后会在堆中产生大量的内存碎片。内存碎片过多会带来很多麻烦，其一就是很难为大对象分配内存。导致的后果就是：堆空间明明还有很多，但就是找不到一块连续的内存区域为大对象分配内存，而不得不触发一次Full GC，这样GC的停顿时间又会变得更长。
针对这种情况，CMS提供了一种备选方案，通过-XX：CMSFullGCsBeforeCompaction参数设置，当CMS由于内存碎片导致触发了N次Full GC后，下次进入Full GC前先整理内存碎片，不过这个参数在JDK9被弃用了。

三色标记算法

介绍完CMS垃圾收集器后，我们有必要了解一下，为什么CMS的GC线程可以和用户线程一起工作。

JVM判断对象是否可以被回收，绝大多数采用的都是「可达性分析」算法，关于这个算法，可以查看笔者以前的文章：大白话理解可达性分析算法。

从GC Roots开始遍历，可达的就是存活，不可达的就回收。

CMS将对象标记为三种颜色：
标记的过程大致如下：

  1. 刚开始，所有的对象都是白色，没有被访问。
  2. 将GC Roots直接关联的对象置为灰色。
  3. 遍历灰色对象的所有引用，灰色对象本身置为黑色，引用置为灰色。
  4. 重复步骤3，直到没有灰色对象为止。
  5. 结束时，黑色对象存活，白色对象回收。

这个过程正确执行的前提是没有其他线程改变对象间的引用关系，然而，并发标记的过程中，用户线程仍在运行，因此就会产生漏标和错标的情况。

漏标

假设GC已经在遍历对象B了，而此时用户线程执行了A.B=null的操作，切断了A到B的引用。

本来执行了A.B=null之后，B、D、E都可以被回收了，但是由于B已经变为灰色，它仍会被当做存活对象，继续遍历下去。
最终的结果就是本轮GC不会回收B、D、E，留到下次GC时回收，也算是浮动垃圾的一部分。

实际上，这个问题依然可以通过「写屏障」来解决，只要在A写B的时候加入写屏障，记录下B被切断的记录，重新标记时可以再把他们标为白色即可。

错标

假设GC线程已经遍历到B了，此时用户线程执行了以下操作：

B.D=null;//B到D的引用被切断
A.xx=D;//A到D的引用被建立


B到D的引用被切断，且A到D的引用被建立。
此时GC线程继续工作，由于B不再引用D了，尽管A又引用了D，但是因为A已经标记为黑色，GC不会再遍历A了，所以D会被标记为白色，最后被当做垃圾回收。
可以看到错标的结果比漏表严重的多，浮动垃圾可以下次GC清理，而把不该回收的对象回收掉，将会造成程序运行错误。

错标只有在满足下面两种情况下才会发生：

只要打破任一条件，就可以解决错标的问题。

原始快照和增量更新

原始快照打破的是第一个条件：当灰色对象指向白色对象的引用被断开时，就将这条引用关系记录下来。当扫描结束后，再以这些灰色对象为根，重新扫描一次。相当于无论引用关系是否删除，都会按照刚开始扫描时那一瞬间的对象图快照来扫描。

增量更新打破的是第二个条件：当黑色指向白色的引用被建立时，就将这个新的引用关系记录下来，等扫描结束后，再以这些记录中的黑色对象为根，重新扫描一次。相当于黑色对象一旦建立了指向白色对象的引用，就会变为灰色对象。

写屏障

这个写屏障指的可不是并发编程里的写屏障哦！这里的写屏障指的是属性赋值的前后加入一些处理，类似于AOP。

CMS采用的方案就是：写屏障+增量更新来实现的，打破的是第二个条件。

当黑色指向白色的引用被建立时，通过写屏障来记录引用关系，等扫描结束后，再以引用关系里的黑色对象为根重新扫描一次即可。

伪代码大致如下：

class A{private D d;public void setD(D d) {writeBarrier(d);// 插入一条写屏障this.d = d;}private void writeBarrier(D d){// 将A -> D的引用关系记录下来，后续重新扫描}
}

尾巴

CMS为了让GC线程和用户线程一起工作，回收的算法和过程比以前旧的收集器要复杂很多。究其原因，就是因为GC标记对象的同时，用户线程还在修改对象的引用关系。因此CMS引入了三色算法，将对象标记为黑、灰、白三种颜色的对象，并通过「写屏障」技术将用户线程修改的引用关系记录下来，以便在「重新标记」阶段可以修正对象的引用。
虽然CMS从来没有被JDK当做默认的垃圾收集器，存在很多的缺点，但是它开启了「GC并发收集」的先河，为后面的收集器提供了思路，光凭这一点，就依然值得记录下来。

CMS与三色标记算法相关推荐

  1. JVM从入门到精通（十）：垃圾回收算法串讲：CMS，G1，三色标记算法

    CMS 并发回收,工作线程和GC线程同时进行,暂停时间短 老年代 分为 四个阶段: 初始标记:需要STW,因为初始的垃圾并不多,因此耗费的时间不长 并发标记:垃圾回收线程和工作线程同时执行.一边产生垃 ...

  2. JVM 调优 2：GC 如何判断对象是否为垃圾，三色标记算法应用原理及存在的问题？

    文章目录 前言 一.如何判断一个对象是否为垃圾? 1.1.reference count(引用计数) 1.2.reference count(引用计数)存在的问题 二.Root Searching(根 ...

  3. 说说关于JVM三色标记算法

    本文来说下关于JVM三色标记算法 文章目录 概述 三色标记算法思想 算法流程 三色标记存在问题 解决办法 CMS回顾 CMS解决办法:增量更新 CMS另两个致命缺陷 G1回顾 G1前置知识 Card ...

  4. JVM 的三色标记算法详解

    本文来说下关于JVM 的三色标记算法. 文章目录 三色标记算法概述 引用计数&可达性分析 分代收集 什么是卡表 卡表的问题 写屏障 伪共享 三色标记算法 基本算法 三色标记算法缺陷 多标 漏标 ...

  5. Go语言实时GC - 三色标记算法

    前言 Go语言能够支持实时的,高并发的消息系统,在高达百万级别的消息系统中能够将延迟降低到100ms以下,很大一部分需要归功于Go高效的垃圾回收系统. 对于实时系统而言,垃圾回收系统可能是一个极大的隐 ...

  6. CMS 中 三色标记概述

    CMS 清理流程 三色标记 概述 三色标记其实就是用三种颜色区分不同的内存区域. 黑色标记:自己已经标记,直接引用的对象区域已经标记 灰色标记:自己标记完成,但引用区域没来得及标记 白色标记:没有遍历 ...

  7. GC垃圾回收的三色标记算法

    GC中用三种颜色标记不同的对象 (1)黑色:本身强引用,并已处理对象中的子引用 (2)灰色:本身强引用,还没处理对象中的子引用 (3)白色:不可达对象 Mark扫描时根据状态进行标记

  8. JVM调优：G1三色标记算法

  9. JVM 三色标记 增量更新 原始快照

    2.1 基本算法 要找出存活对象,根据可达性分析,从GC Roots开始进行遍历访问,可达的则为存活对象: 最终结果:A/D/E/F/G 可达 我们把遍历对象图过程中遇到的对象,按"是否访问 ...

最新文章

  1. umi脚手架搭建的项目_15天零成本搭建静态博客，托管于Github Page
  2. 技术图文：如何在leetcode上进行算法刻意练习？
  3. Bug总结：python语言中出现的import error错误的解决思路
  4. 一位资深程序员的成长故事
  5. mysql5.5.8编译安装_MySQL5.5.8源代码编译安装
  6. 3-5：类与对象中篇——默认成员函数之运算符重载
  7. python sklearn 支持向量机_python机器学习库sklearn之支持向量机svm介绍
  8. 散粉在哪个步骤用_新手化妆步骤+50个美妆小技巧+化妆知识扫盲
  9. Nginx 从入门到放弃（三）
  10. anaconda双版本python_Anaconda中安装多版本Python及切换
  11. WorkPlus协同办公系统的优势有哪些？
  12. IETester更新至最新版已经兼容Windows7（附下载地址及Debugbar插件）
  13. centos7 ipv4配置
  14. 第三人称计算机获奖感言,个人获奖感言50字第三人称
  15. C++程序设计重点总结（谭浩强版）
  16. 接雨水,Leet#42
  17. 基于Android的记账APP论文,基于Android平台的手机记账系统的设计与实现
  18. Hypervisor介绍(二)
  19. 多地政府提及元宇宙发展 | 产业区块链发展周报
  20. word文件的打开密码如何破解

热门文章

  1. 矩阵的基本运算（一）
  2. 淘宝宝贝描述模板DIV无法使用BACKGROUND属性的终极解决方案
  3. Database---Access Methods
  4. Transformer Cognos操作
  5. 网站性能优化解决方案
  6. 第四章第十三题（判断元音还是辅音）(Vowel or consonant?)
  7. 几句话说清楚AMD® Ryzen CPU里的PBO
  8. C语言循环链表（不带头结点）解约瑟夫问题的一种变形
  9. 用GPOPS2解最优控制问题
  10. 如何解决2D CAD DraftSight闪退或停止工作问题，干货！