CMS回收器:低延迟
在JDK1.5,HotSpot推出了一款在强交互应用中几乎可认为有划时代意义的垃圾收集器:CMS(Concurrent-Mark-Sweep)收集器,这款收集器是HotSpot虚拟机中第一款真正意义上的并发收集器,它第一次实现了让垃圾收集线程与用户线程同时工作。
CMS收集器的关注点是尽可能缩短垃圾收集时用户线程的停顿时间。停顿时间越短,就越适合与用户交互的程序,良好的响应速度能提升用户体验。
CMS垃圾收集算法采用标记-清除算法,并且也会”Stop-The-World"
CMS垃圾收集器的工作过程如下:
CMS整个过程分为4个主要阶段,即初始化标记阶段、并发标记阶段、重新标记阶段和并发清除阶段。
1.初始标记阶段:在这个阶段中,程序中的所有工作线程都将会因为”Stop-The-World"机制而出现短暂的暂停,这个阶段的主要任务仅仅只是标记出GC Roots能直接关联到的对象。一旦标记完成之后就会恢复之前被暂停的所有应用线程。由于直接关联对象比较小,所以这里的速度非常快。
2.并发标记阶段:从GC Roots的直接关联对象开始遍历整个对象图的过程,这个过程耗时较长但是不需要停顿用户线程,可以与垃圾收集线程一起并发运行。
3.重新标记阶段:由于在并发标记阶段中,程序的工作线程会和垃圾收集线程同时运行或者交叉运行,因此为了修正并发标记期间,因用户线程继续运行而导致标记产生变动的那一部分对象的标记记录,这个阶段的停顿时间通常会比初始标记阶段稍长一些,但也远比并发标记阶段的时间短。
4.并发清除阶段:此阶段清理删除掉标记阶段判断的已经死亡的对象,释放内存空间。由于不需要移动存活对象,所以这个阶段也是可以与用户线程同时并发的。
CMS收集器的垃圾收集算法采用的是标记-清除算法,这意味着每次执行完内存回收后,由于被执行内存的无用对象所占用的内存空间极有可能是不连续的一些内存块,不可避免地将会产生一些内存碎片。那么CMS在为新对象分配内存空间时,将无法使用指针碰撞技术,而只能够选择空闲列表执行内存分配。
CMS的优点:
1.并发收集。
2.低延迟。
CMS的缺点:
1.会产生内存碎片,导致并发清除后,用户线程可用的空间不足,在无法分配大对象的情况下,不得不提前触发Full GC。
2.CMS收集器对CPU资源非常敏感。在并发阶段,它虽然不会导致用户停顿,但是会因为占用了一部分线程而导致应用程序变慢,总吞吐量会降低。
3.CMS收集器无法处理浮动垃圾。可能出现"Concurrent Mode Failure"失败而导致另一次Full GC的产生。在并发清理阶段用户线程还在运行着,伴随程序运行自然就还会有新的垃圾不断产生,这一部分垃圾出现在标记过程之后,CMS无法在单次收集中处理掉它们,只能等下次GC时再清理掉。这一部分垃圾就称为”浮动垃圾“。
参数设置:
总结:
1.如果你最小化地使用内存和并行开销,就选择Serial GC。
2.如果你想要最大化应用程序地吞吐量,就选择Parallel GC。
3.如果你想要最小化GC的中断或停顿时间,就选择CMS GC。