JVM面试必问的CMS，你懂了吗？

　　前言
　　虽然CMS已经是很古老的垃圾回收器了，大家现在动不动就G1、ZGC啥的，但是据我所了解，还是有很多公司的生产环境主要使用的CMS，包括我自己呆过的几家大厂也是。
　　因此在JVM面试中，CMS也是问的最多的，包括我自己现在面试别人时，问到JVM这一块，我也喜欢从CMS开始，逐渐深入。
　　不多废话，今天我们就来盘他。
　　正文
　　1、什么是卡表（cardtable）？
　　试想一下，在进行YGC时，如何判断是否存在老年代到新生代的引用？
　　一个简单的办法是扫描整个老年代，但是这个代价太大了，因此JVM引入了卡表来解决这个问题。
　　卡表又称为卡片标记（cardmarking），由PaulR。Wilson和ThomasG。Moher在1989年发表的论文里提出。
　　其原理为，在逻辑上将老年代空间分割为若干个固定大小的连续区域，分割出来的每一个个区域就称为卡片（card）。另外，为每个卡片准备一个与其对应的标记位，最简单的实现方案是由字节数组实现，以卡的编号作为索引。每个卡的大小通常介于128512字节之间，一般使用2的幂字节大小，例如HotSpot使用512字节。
　　当卡片内部发生引用变化时（指针写操作），写屏障会将该卡在卡表中对应的字节标记为脏（dirty）。
　　有了卡表后，在YGC时，只需将卡表中被标记为dirty的card也作为扫描范围，就可以保障不扫描整个老年代也不会有遗漏了。
　　2、什么是moduniontable？
　　通过上面对cardtable的介绍，我们知道cardtable会记录下老年代所有发生过引用变化对象所在的card，而CMS在并发标记等阶段，也需要记录下老年代发生引用变化的对象以便后续重新扫描，是否可以直接复用cardtable？
　　答案是不行的，这是因为每次YGC过程中都涉及重置和重新扫描cardtable，这样是满足了YGC的需求，但却破坏了CMS的需求，CMS需要的信息可能被YGC给重置掉了。为了避免丢失信息，于是在cardtable之外另外加了一个Bitmap叫做moduniontable。
　　在CMS并发标记正在运行的过程中，每当发生一次YGC，当YGC要重置cardtable里的某个记录时，就会更新moduniontable对应的bit，相当于将cardtable里的信息转移到了moduniontable里。
　　这样，最后到Finalremark的时候，cardtable加moduniontable就足以记录在并发标记过程中老年代发生的所有引用变化了。
　　3、CMS垃圾收集的过程？
　　CMS垃圾收集的过程网上通常有两个版本，4个步骤的和7个步骤的，两个版本其实都是对的。
　　4个步骤应该主要是跟随周志明的说法，而CMS的相关论文其实也是按4个步骤介绍。
　　7个步骤则应该更多是从CMS的日志得出的说法，而7个步骤里其实也包含了上述的4个步骤，可以理解为7个步骤是更细的说法。
　　个人而言，我会更喜欢7个步骤的说法，因此这边介绍下7个步骤的过程。
　　1）初始标记（InitialMark）
　　STW（stoptheworld），遍历GCRoots，标记GCRoot直达的对象。
　　2）并发标记（ConcurrentMark）
　　从初始标记阶段被标记为存活的对象作为起点，向下遍历，找出所有存活的对象。
　　同时，由于该阶段是用户线程和GC线程并发执行，对象之间的引用关系在不断发生变化，对于这些对象，都是需要进行重新标记的，否则就会出现错误。为了提升重新标记的效率，JVM会使用写屏障（writebarrier）将发生引用关系变化的对象所在的区域对应的card标记为dirty，后续只需要扫描这些dirtycard区域即可，避免扫描整个老年代。
　　3）并发预处理（ConcurrentPreclean）
　　该阶段存在的意义主要是为了尽可能降低FinalRemark阶段的耗时，因为FinalRemark阶段是STW的。
　　该阶段主要做的事是将上一阶段被标记为dirty的card所对应的区域进行重新扫描标记，处理并发阶段发生引用变化的对象。
　　4）可中断的并发预处理（ConcurrentAbortablePreclean）
　　该阶段和并发预处理做的事是基本一样的，也是主要处理dirtycard。区别在于并发预处理只执行一次，而本阶段会一直循环执行，直到触发终止条件。
　　终止条件有以下几个：循环次数超过阈值CMSMaxAbortablePrecleanLoops，默认是0，也就是没有循环次数的限制。处理时间达到了阈值CMSMaxAbortablePrecleanTime，默认是5秒。Eden区的内存使用率达到了阈值CMSScheduleRemarkEdenPenetration，默认为50。
　　同时该阶段有一个触发前提：Eden区的内存使用量大于参数CMSScheduleRemarkEdenSizeThreshold，默认是2M。
　　5）最终标记重新标记（FinalRemark）
　　STW（stoptheworld），主要做两件事：遍历GCRoots，重新扫描标记遍历被标记为dirty的card，重新扫描标记
　　6）并发清理（ConcurrentSweep）
　　清理未使用的对象并回收它们占用的空间。
　　7）并发重置（ConcurrentReset）
　　重置CMS算法用于打标的数据结构（markBitMap），为下一次收集做准备。
　　4、CMS存在的问题
　　1）使用的标记清除算法，可能存在大量空间碎片。
　　调优：开启CMS压缩，查看参数是否合理。开启CMS压缩，在FGC时执行压缩，默认为trueXX：UseCMSCompactAtFullCollection执行几次FGC才执行压缩，默认为0XX：CMSFullGCsBeforeCompaction0
　　2）并发清理可能出现ConcurrentModeFailure失败而导致另一次FullGC的产生
　　调优：可能是触发GC的比例太高，适当调低该值。CMS触发GC的比例XX：UseCMSInitiatingOccupancyOnlyXX：CMSInitiatingOccupancyFraction70
　　3）对CPU资源非常敏感。在并发阶段，会因为占用了一部分线程（或者说CPU资源）而导致应用程序变慢，总吞吐量会降低。CMS默认启动的回收线程数是（CPU数量3）4。
　　调优：可能是并发线程数设置太高，适当调低该值。CMS并发线程数XX：ConcGCThreadsX
　　以上的调优只是针对一些可能性较大的问题给的建议，具体还是需要结合场景和完整的JVM参数去分析，各个参数可能都会影响到整体的GC效率。
　　5、FinalRemark阶段为什么还需要遍历GCRoots？
　　这是因为CMS的写屏障（writebarrier）并不是对所有会导致引用变化的字节码生效，例如不支持astoreX（把栈顶的值存到本地变量表）。
　　至于为什么不为astoreX添加写屏障，R大认为是栈和年轻代属于数据快速变化的区域，对于这些区域使用写屏障的收益比较差。
　　6、FinalRemark阶段还需要遍历GCRoots，那之前的标记工作不是白做了？
　　不是的。
　　在三色标记法中（见下面介绍），如果扫描到被标记为黑色的对象就会终止，而之前的并发标记和预处理已经完成了绝大部分对象的标记，也就是此时大部分对象已经是黑色了，因此FinalRemark阶段的工作其实会减少很多。简单来说就是：遍历的广度不变，但是深度变浅了。
　　7、三色标记算法？
　　三色标记算法由EdsgerW。Dijkstra等人在1978年提出，是一种增量式垃圾回收算法，增量式的意思是慢慢发生变化的意思，也就是GC和mutator（应用程序）一点点交替运行的手法。
　　与其相反的则是停止型GC，也就是GC时，mutator完全停止，GC结束再恢复运行。三色标记算法顾名思义就是将GC中的对象分为三种颜色，这三种颜色和所包含的意思如下：白色：还未搜索过的对象。在回收周期的开始阶段，所有对象都为白色，而在回收周期结束时，所有白色对象均为不可达对象，也就是要回收的对象。
　　灰色：正在搜索的对象。已经被搜索过的对象，但是该对象引用的对象还未被全部搜索完毕。
　　黑色：搜索完成的对象。本身及其引用的所有对象都被搜索过，黑色对象不会指向白色对象，同时黑色对象不会被重新搜索，除非颜色发生变化。
　　我们以GC标记清除算法为例简单的说明一下。
　　GC开始运行前所有的对象都是白色。GC一开始运行，所有从根能到达的对象都会被标记为灰色，然后被放到栈里。GC只是发现了这样的对象，但还没有搜索完它们，所以这些对象就成了灰色对象。
　　灰色对象会被依次从栈中取出，其子对象也会被涂成灰色。当其所有的子对象都被涂成灰色时，该对象就会被涂成黑色。当GC结束时已经不存在灰色对象了，活动对象全部为黑色，垃圾则为白色。
　　下面是一个三色标记算法的示例动图，大家参考着理解。
　　明白了三色标记算法后，再回过头去看第5题，是不是顿时就明白了。
　　8、三色标记算法存在的问题？
　　三色标记算法是增量式垃圾回收算法，mutator可能会随时改变对象引用关系，因此在并发下会存在漏标和错标（多标）。
　　1）漏标
　　直接通过一个简单的例子来看：
　　假设当GC线程执行到时刻1时，此时应用线程先执行了步骤1和2，也就是到了时刻3的场景，GC线程继续执行。
　　此时对象Z只被黑色对象X所引用，而黑色对象是不会被继续扫描的，因此扫描结束后Z仍然是白色对象，也就是时刻4，此时白色对象Z则会被当做垃圾而回收。
　　2）错标（多标）
　　直接通过一个简单的例子来看：
　　假设当GC线程执行到时刻1时，此时应用线程先执行了步骤1，也就是到了时刻2的场景，GC线程继续执行。
　　此时对象Z是灰色对象，GC线程对其进行搜索，搜索结束后将其标记为黑色，也就是时刻3，此时对象Z其实没有到GCRoots的引用，理应被回收，但是因为被错误的标记为黑色，而在本次GC中存活了下来。
　　错标和漏标都是三色标记算法存在的问题，但是两者带来的后果有本质的不同。
　　错标使得死亡的对象被当做存活，导致出现浮动垃圾，此时不影响程序的正确性，这些对象下次GC时回收就可以了。
　　漏标使得存活的对象被当做死亡，这个会导致程序出错，带来不可预知的后果，这个是不能接受的，因此漏标是三色标记算法需要解决的问题。
　　通过实验追踪，Wilson发现，只有当以下两个条件同时满足时才会出现漏标问题：
　　1）将某一指向白色对象的引用写入黑色对象
　　2）从灰色对象出发，最终到达该白色对象的所有路径都被破坏
　　9、增量更新和起始快照
　　为了解决三色标记算法的漏标问题，产生了两种比较著名的解决方案：增量更新和起始快照，CMS和G1就是采用了这两种解决方案，CMS使用的增量更新，G1使用的起始快照。
　　漏标问题的出现必须同时满足上述的两个条件，因此解决办法只需破坏两个条件之一即可。
　　1）增量更新（Incrementalupdate）
　　使用写屏障（writebarrier）拦截所有新插入的引用关系，将其记录下来，最后以这些引用关系的源头作为根，重新扫描一遍即可解决漏标问题。
　　增量更新破坏的是条件1，当插入黑色对象到白色对象的引用时，写屏障会记录下该引用，后续重新扫描。
　　以上面的漏标为例，就是拦截步骤1：X。bY。a，记录下X，然后重新扫描对象X。
　　2）起始快照（SATB，snapshotatthebegin）
　　使用写屏障拦截所有删除的引用关系，将其记录下来，然后将被删除的引用关系所指向的对象会被当作存活对象（非白色），重新扫描该对象。
　　SATB抽象的说就是在一次GC开始时刻是存活的对象，则在本次GC中都会被当做存活对象，此时的对象形成一个逻辑快照，这也是起始快照名字的由来。
　　起始快照破坏的是条件2，当到白色对象的引用断开时，写屏障会记录下该引用，将该对象当作存活对象，后续继续扫描该对象的引用。
　　以上面的漏标为例，就是拦截步骤2：Y。anull，将Z作为存活对象，然后重新扫描对象Z。
　　10、CMS中的FinalRemark（重新标记）阶段较慢，怎么分析和解决？
　　CMS的整个垃圾回收过程中只有2个阶段是stoptheworld，一个是初始标记，一个是重新标记，初始标记只标记GCRoots直达的对象，因此一般不会耗时太久，而重新标记出现耗时久的现象则比较多见，通常如果CMSGC较慢，大多都是重新标记阶段较慢导致的。
　　FinalRemark阶段比较慢，比较常见的原因是在并发处理阶段引用关系变化很频繁，导致dirtycard很多、年轻代对象很多。
　　比较常见的做法可以在FinalRemark阶段前进行一次YGC，这样年轻代的剩余待标记对象会下降很多，被视为GCRoot的对象数量骤减，FinalRemark的工作量就少了很多。在remark之前尝试进行清理，默认值为falseXX：CMSScavengeBeforeRemark
　　通常增加XX：CMSScavengeBeforeRemark都能解决问题，但是如果优化后还是耗时严重，则需要进一步看具体是哪个小阶段耗时严重。
　　FinalRemark具体包含了若干个小阶段：weakrefsprocessing、classunloading、scrubstringtable等，从日志里可以看出来每个小阶段的耗时，根据耗时的阶段再进行针对性的分析，可以查阅源码或者查阅相关资料来帮助分析。
　　以比较常见的weakrefsprocessing为例：
　　这边的weakrefs不是单指WeakReference，而是包括了：SoftReference、WeakReference、FinalReference、PhantomReference、JNIWeakReference，这边应该是除了强引用外的所有引用都被归类为weak了。
　　因此，我们首先添加以下配置，打印出GC期间引用相关更详细的日志。打印GC的详细信息XX：PrintGCDetails打印在GC期间处理引用对象的时间（仅在PrintGCDetails时启用）XX：PrintReferenceGC
　　然后根据每个引用的耗时，定位出耗时严重的引用类型，然后查看项目中是否存在对该引用类型不合理的使用。
　　另外一种比较简单粗暴的办法是可以通过增加引用的并行处理来尝试解决，通常会有不错的效果。启用并行引用处理，默认值为falseXX：ParallelRefProcEnabled
　　而如果是scrubstringtable阶段耗时，则可以分析项目中是否存在不合理的使用internedstring，其他的也类似。原文链接：https：mp。weixin。qq。comsSOPhwHxPNscIMuQqFaRIA
　　原作者：程序员囧辉