cms(Concurent Mark Sweep)收集器
C:Concurrent
M:标记(marking)对象:GC必须记住那些对象可达,以便删除不可达对象
S:清除(sweeping): 删除未标记的对象并释放它们的内存。
CMS是一种以最短停顿时间为目标的收集器,使用CMS并不能达到GC效率最高,但它尽可能减低GC时服务的停顿时间。
*使用标记-清除算法(Mark Sweep),在运行时会产生内存碎片,虚拟机提供了参数开启CMS收集结束后再进行一次内存压缩。
-XX:+UseConcMarkSweepGC
激活CMS收集器。默认HotSpot JVM使用的是并行收集器
-XX:+UseCMSCompactAtFullCollection
设置在垃圾收集器后是否需要一次内存碎片整理过程,仅在CMS收集器时有效
-XX:+CMSFullGCBeforeCompaction
设置CMS收集器在进行若干次垃圾收集后再进行一次内存碎片整理过程
通常与UseCMSCompactAtFullCollection参数一起使用*
CMS垃圾回收整个过程分为六个步骤:
- 初始标记 (CMS initial mark) 会STW(Stop The Word)为了收集应用程序的对象引用,需要暂停应用程序线程,该阶段完成后,应用程序再次启动。
并发标记(COMS concurrent mark)
从第一阶段收集到的对象引用开始,遍历所有其他的对象引用。并发预清理(CMS -concurrent-preclean)
改变当运行第二阶段时,由应用程序线程产生的对象引用, 以更新第二阶段的结果。- 重新标记(CMS remark)会STW
由于第三阶段是并发的,对象引用可能会发生进一步改变,因此应用程序线程会再一次被暂停以更新这些变化
并且在进行实际的清理之前确保一个正确的对象引用视图 - 并发清理(CMS concurrent sweep)
所有不再被引用的对象将从堆清楚掉 - 并发重置:
收集器做一些收尾的工作,以便下一次GC周期能有一个干净的状态
CMS的两个挑战:
- 堆碎片
CMS收集器默认并没有任何碎片整理的机制。所以可能会出现这样的情形:
即使总的堆大小远没有耗尽但却不能分配对象,仅仅是因为没有足够连续的空间完全容纳对象。
当这种事发生后,JVM会触发Full GC
- 对象分配率高
获取对象实例的频率高于收集器清除堆里死对象的频率
并发模式失败: 老年代没有足够的可用空间来容纳一个从年轻代提升过来的对象
此时JVM会执行堆碎片整理:触发Full GC
当这些情形之一出现的时候,经常被证实是老年代有大量不必要的对象。
一个可行的办法: 增加年轻代的堆大小(增加Survior区的个数),以防止年轻代生命周期短的对象提前进入老年代。
其他方法: 利用jmap和jhat分析过度的对象分配,找出这些对象,最终减少这些对象的申请。