JVMGC——并发收集器(CMS)

 CMS(Concurrent 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垃圾回收整个过程分为六个步骤:

1. 初始标记 (CMS initial mark)  会STW(Stop The World)

为了收集应用程序的对象引用需要暂停应用程序线程

该阶段完成后,应用程序线程再次启动


2. 并发标记 (CMS concurrent mark)

从第一阶段收集到的对象引用开始,遍历所有其他的对象引用


3. 并发预清理(CMS-concurrent-preclean)

改变当运行第二阶段时,由应用程序线程产生的对象引用,以更新第二阶段的结果


4. 重新标记 (CMS remark)  会STW

由于第三阶段是并发的,对象引用可能会发生进一步改变,因此应用程序线程会再一次被暂停以更新这些变化

并且在进行实际的清理之前确保一个正确的对象引用视图


5. 并发清理 (CMS concurrent sweep)  

所有不再被引用的对象将从堆里清除掉


6. 并发重置:

收集器做一些收尾的工作,以便下一次GC周期能有一个干净的状态




CMS的两个挑战:

1. 堆碎片

CMS收集器默认并没有任何碎片整理的机制。所以可能会出现这样的情形:

即使总的堆大小远没有耗尽但却不能分配对象,仅仅是因为没有足够连续的空间完全容纳对象

当这种事发生后,JVM会触发Full GC

 

2. 对象分配率高

获取对象实例的频率高于收集器清除堆里死对象的频率

并发模式失败: 老年代没有足够的可用空间来容纳一个从年轻代提升过来的对象

此时JVM会执行堆碎片整理:触发Full GC

 

当这些情形之一出现的时候,经常被证实是老年代有大量不必要的对象

一个可行的办法: 增加年轻代的堆大小(增加Survior区的个数),以防止年轻代生命周期短的对象提前进入老年代。

其他方法: 利用jmap和jhat分析过度的对象分配,找出这些对象,最终减少这些对象的申请。





你可能感兴趣的:(java虚拟机(JVM),javase)