CMS垃圾收集器介绍

为期两个月的阿里JVM实习结束了。

在离开科大去实习之前准备了一篇关于Java5中提出的Concurrent Mark Sweep收集器的介绍。

现在贴出来:

CMS垃圾收集器
                                                            中国科学技术大学 软件学院 曾鸣堃
一.总体介绍:
       CMS是一款优秀的垃圾收集器。众所周知,在oracle公司的Hotspot的架构中,大体上采用分代回收的机制。其中出生代又采用了拷贝复制的方法。如果对象在初生代内存活超过一定次数之后,就可以晋升到老生代中,而CMS垃圾收集器就是专门用来对老生代做收集。随着现代硬件的发展,更多的企业及服务最关注的点在GC的停顿时间,而CMS恰好是一种以获取最短回收停顿时间为目标的收集器,可以给这类服务带来最好的服务效果。       
       
二.算法剖析:
Mostly-Concurrent collection
这个算法是由Boehm等人提出的,并设计了一种基于三色(tricolor)的收集器。它对整个老年代做一个写屏障,所以如果要对老年代做写操作的时候会讲对应的对象置为灰色。它主要分为以下四个阶段:
1).初始标记阶段
暂停所有的其他线程,并记录下直接与root相连的对象。
2).并发标记阶段
同时开启GC和用户线程,用一个闭包结构去记录可达对象。但在这个阶段结束,这个闭包结构并不能保证包含当前所有的可达对象。因为用户线程可能会不断的更新引用域,所以GC线程无法保证可达性分析的实时性。所以这个算法里会跟踪记录这些发生引用更新的地方。
3).最终确认标记阶段
将上一阶段做了指针更新的区域和root合并为一个伪root集合,并对其做tracing。从而可以保证真正可达的对象一定被标记了。但同时也会产生一部分被标记为可达,但其实已经是不可达的区域,由于已经没有了到达这个区域的路径,所以并没有办法将它的标志位置为0,则造成了一个暂时的内存泄漏,但这部分空间会在下一次收集阶段被清扫掉。
4).并发清扫阶段
开启用户线程,同时GC线程开始对为标记的区域做清扫。这个过程要注意不要清扫了刚被用户线程分配的对象。一个小trick就是在这个阶段,将所有新分配的对象置为可达的。  
下面我们来看一个运用了Mostly-Concurrent collection算法的例子:
   
a)处于并发标记阶段,经历了初始阶段标记的a。进入并发标记,记录了b, c, d。
b)依旧处于并发标记阶段,b和e发生了指针更新,并且被collector将其对应域置为dirty。
c)处于最终确认标记阶段,对dirty区别做一个重新扫描,并且标记上d。注意此时c已经是垃圾了,但我们无法对它的标志位做更新。
d)处于并发清扫阶段,会将f清扫掉。而c只能等到下一轮的收集,再去回收它咯。                                                                                                          
Mostly Concurrent Collection in a Generational System

       现代的JVM就是利用CMS收集器对它的老生代做收集。这中间涉及到具体的并发标记的时候,用到Card Table这个概念。因为在Hotspot JVM的世代回收过程中,新生代的空间会比较小,而老生代的空间会比较大。基于老生代空间大,变更小的特点,为了尽量减少GC引起的停顿时间,采用了停顿时间最短的CMS收集器。在CMS的并发标记的过程中,它会将整个老生代的空间切割为一个个block,每个block对应一个card。并且对整个老生代加上write barrier。从而在并发的标记过程中,用card来记录堆内发生写操作的区域。
       在具体的实现write barrier时,Hosking和Moss发现操作系统提供的内存保护屏障开销太大了,所以他们重新设计了一个只要2到3条指令就可以实现同样功能的barrier,这样意味着更小的开销,从论文里看这应该是一个轻量级的软件层面的barrier。但这种基于虚拟存储的系统并不能区分对每个block中的基本类型变量做修改还是对其中的引用类型变量做修改,所以会出现很多dirty但并没有做指针更新的block。
       由于card还是包含了很多其他信息。所以为了节省更多的空间提高局部性,又提出了Mod Union Table。将每个dirty位单独拉出来做成一个bitmap或者bytemap。从而减少空间开销,提高定位堆中dirty块的速度。
     在标记过程中,为了减少collector和mutator之间在读取Object头部而产生的相互干扰,我们并没有将mark bit放到Object的头部。而是将他们抽出来放到外部作为一个单独的数据结构。在具体的实现过程中,对heap内的每4Byte大小做一个对应的bit标记位。通常为了减少GC的停顿时间,我们会将所以root可达的对象放入到这个集合内,称为remember set。但考虑到GC的时候本身就是缺乏资源的,所以这些数据结构不应该占据大量的空间。所以具体的实现过程中只存取了与root直接相邻的对象。

三.CMS的具体过程
  • 初始标记(STW initial mark)
      在具体的实现的时候,考虑到GC停顿时间和空间利用开销的因素,我们选择了一个折中的办法。即用了一个外部的bitmap增强局部性尽量减小GC的停顿时间,同时在to-scanned-set内放了直接与root相连的object,并将其标志位置为1,这样可以减小空间的开销。注意这个阶段需要暂停所有的非GC线程。
  • 并发标记(Concurrent marking)
     在第二阶段的并发标记的阶段,GC线程会线性的扫描整个堆的bitmap。在线性的遍历bitmap的过程中,如果发现一个标志位为1的object则将它压入to-scanned-set内(具体实现用一个stack来维护)。当stack满的时候,进入循环,将栈内的对象一个个弹出来并扫描其中的引用域。同时遵循如下的规则: (1)引用的对象地址比自己低,注意此时按线性去遍历bitmap已经走过了这个位,则我们要将当前的引用对象压入栈中,并对其标志做一次更新操作置为1。(2)引用对象地址比自己高,则只用将对应的bit标记一下即可,因为根据线性的扫描,之后会扫到他,从而做有关的压栈扫描处理。从而不断的做循环,直到这个栈为空并且扫描结束,注意这个过程发生在并发的阶段,这意味着除了collector在做标记还有mutator在制造垃圾。这种策略的缺陷在于它需要对整个堆的做线性遍历,而不是简单的tracing( tracing是一个图遍历的过程,其算法复杂度为O(N+E) )。
  • 并发预清理(Concurrent Precleaning)
     为了尽量减少下一阶段STW的时间。增加了预清理的阶段,主要是对并发标记过程中留下的dirty位做一个tracing。注意这里是并发的执行,所以同时也会对card table和标记表做更新。一般实现采用不多循环遍历dirty表做tracing并对它做clean操作,直到预清理清楚了三分之一以上的dirty表则退出循环(也有的采用的是dirty数小于1000则退出循环)。
  • 重新标记(STW Remark)
     暂停所有用户线程,从dirty和root入口做tracing,确保所有可达对象做了标记。
  • 并发清理(Concurrent sweeping)
    并发的开启GC和用户线程,其中涉及到对相邻free block的整合问题。因为它可能会由mutator和collector对freeList的操作产生数据的不一致性。所以为了保证一致性,需要对空闲块的操作加上外部锁(exclusion lock)。
  • 并发重置(Concurrent reset)
     对标记的表和记录dirty的表做清零。并且重置CMS收集器的其他数据结构,等待下一次垃圾回收。

四.总结
优点:
1).将stop-the-world的时间降到最低,能给电商网站用户带来最好的体验。                
2).尽管CMS的GC线程对CPU的占用率会比较高,但在多核的服务器上还是展现了优越的特性,目前也被部署在国内的各大电商网站上。
缺点:
1).对CMS在单核和多核机器上做测试。发现CMS在收集过程中会大量占用CPU的时间。所以在第二个阶段会比较漫长,所以一般将其设置在多核机器上。并且对于CMS在单核机器上的表现设计了一套启发式控制。这种控制将收集器看作一个掠夺者,而收集器会尽量赶在用户线程分配新的对象之前完成收集的工作。同样也有可能会出现用户线程希望分配对象,但目前空间不够,则需要停下收集器,这样会让整个收集时间大大加长。所以这时候一搬会选择扩张堆的大小。
2).Mark Sweep算法一直令人诟病的碎片问题,造成了堆空间的浪费以及利用率的下降。
3).需要较大的内存空间去运行,因为在很多并行的阶段,要考虑到用户程序运行时也要分配空间。所以一般选择在堆利用率达到一个常数的时候就开启CMS的收集。可以在VM argument里来设置这个阀值。(–XX:CMSInitiatingOccupancyFraction =n,n=0~100)
4).会产生浮动垃圾,由于CMS并发清理阶段用户线程还在运行着,伴随程序自然就还会有新的垃圾不断产生,这一部分垃圾出现在标记过程之后,CMS无法在当次收集中处理掉它们,只好等到下一次GC去处理。
 


阅读更多
文章标签: cms jvm concurrent
个人分类: JVM
想对作者说点什么? 我来说一句

没有更多推荐了,返回首页

关闭
关闭
关闭