cms垃圾回收-编程知识

cms垃圾回收

CMS概述
CMS收集器整体流程
- 初始标记
- 并发标记
- 重新标记
- 并发清除
CMS卡表
- 什么是卡表(card table)
- 什么是mod-union table

CMS概述

CMS(Concurrent Mark Sweep)收集器是Java虚拟机中的一种老年代(old Generation)垃圾收集器，他主要目标是减少垃圾收集时的应用程序停顿（Stp）时间。

CMS使用并发的方式执行垃圾回收，使用的是“标记-清理”算法，尽量减少在垃圾收集过程中程序的暂停时间，适用于对服务响应速度要求较高的场景，例如互联网的B/S系统的服务端Java应用。

CMS垃圾收集器作为一款专注降低停顿时间的垃圾回收器，其主要特点是低停顿和并发：

并发
CMS被设计为一款并发、低停顿的垃圾收集器，使得在垃圾回收过程中用户线程停顿时间很短，有助于保障系统的响应速度。
低停顿
由于其并发特性，CMS的停顿时间相对较短，适用于对服务响应速度要求高的应用场景。

但是，由于CMS的实现机制，也存在着下面这些问题：

对CPU资源敏感：
CMS对CPU资源敏感，因为在并发阶段虽然不会导致用户线程停顿，但会占用一部分线程（CPU资源），可能导致应用程序整体变慢，降低总吞吐量。
无法处理浮动垃圾
由于CMS在并发清理阶段用户线程仍在运行，新的垃圾可能在标记过程之后（重新标记之后）的“并发清理阶段”产生。因为在并发清理阶段用户线程和GC线程是并发运行的，而CMS不能在当前收集中处理这部分浮动垃圾。
所以CMS收集器必须预留一部分空间给用户用户线程使用，不能等到老年代占用100%再进行收集
对CPU数量要求较高
CMS默认启动的回收线程数为（CPU数量+3）/4，当CPU不足4个时，可能对用户程序影响较大。
内存碎片问题
基于“标记-清除”算法的CMS会导致大量空间碎片的产生，可能对大对象分配的时候可能会产生Full GC，因为可能出现老年代空间虽有剩余但无法找到足够大连续空间来分配当前对象。

CMS收集器整体流程

CMS垃圾收集器是一种并发执行的垃圾回收器。其执行过程分为初始标记，并发标记，重新标记，和并发清理。流程如下：

在这里插入图片描述

初始标记

初始标记只是标记GC Roots能直接关联到的对象，但需要“Stop The World”停顿，即在此期间暂停所有应用线程。这个过程在JDK 7 之前是单线程（因为GC Roots直接关联的对象相对较少），JDK 8之后是多线程的方式进行初始标记。
由于GC Root直接关联的对象小，因此可以快速的将这些对象标记出来，以减少“Stop The World”的时间。

并发标记

与应用线程一起运行，是CMS最主要的工作阶段，通过直达对象，扫描全部的对象，进行标记

重新标记

STW，修正并发标记时由于应用程序还在并发运行产生的对象的修改，多线程，速度快，需要全局停顿

由于在并发标记阶段，用户线程还是在工作的，因为有可能会产生新的对象，新对象主要通过以下三个途径产生:

年轻代对象晋升到老年代，可能产生新的存活对象
大对象直接被分配到老年代，可能产生新的存活对象
老年代和年轻代对应的应用关系发生变化。

JVM会通过Card（卡片）的方式将发生变化的老年代区域标记为“脏”区域，也就是所谓的卡片标记（Card Marking）来对新增对象的存活状态进行重新标记。

并发清除

与应用程序一起运行，为何采用清除算法？CMS主要关注低延迟，因而采用并发方式，清理垃圾时，应用程序还在运行，如何采用压缩算法，则涉及到要移动应用程序的存活对象，此时不停顿，是很难处理的，一般需要停顿下，移动存活对象，再让应用程序继续运行，但这样停顿时间变长，延迟变大，所以CMS采用清除算法。

CMS卡表

什么是卡表(card table)

试想一下，在进行young gc时，如何判断是否存在老年代到新生代的引用？
一个简单的办法是扫描整个老年代，但是这个代价太大了，因此jvm引入了卡表来解决这个问题。

卡表又被卡片标记(card marking),其原理为，在逻辑上将老年代空间分割为若干个固定大小的连续区域，分割出来的每一个区域就称为卡片(card)。另外每个卡片又一个与其对应的标记位，最简单的实现方案是由字节数组实现，以卡的编号作为索引，每个卡的大小通常介于128-512字节之间，一般使用2的幂字节大小，例如hotspot使用512字节。

当卡片内部发生应用变化时(指针写操作)，写屏障会将该卡在卡表中对应的字节标记为脏(dirty)。

有了卡表后，在YGC时，只需要将卡表中被标记为dirty的card也作为扫描范围，就可以保证整个老年代也不会有遗漏了。