JVMGC——并发收集器(CMS)
来源:互联网 发布:不同国家制造业数据 编辑:程序博客网 时间:2024/05/21 08:48
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收集器时有效
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分析过度的对象分配,找出这些对象,最终减少这些对象的申请。
- JVMGC——并发收集器(CMS)
- JVMGC——垃圾收集器的分类
- Java垃圾回收精粹——串行收集器、并行收集器以及并发标记清理收集器(CMS)
- jVMgc-6 吞吐量收集器
- jvm实用参数--并发(CMS)收集器
- GC——CMS收集器
- 并发垃圾收集器(CMS)为什么没有采用标记-整理算法来实现?
- [jvm][面试] 并发收集器 CMS(Concurrent Mark-Sweep)
- JVMGC——基本垃圾回收算法
- 垃圾回收器——CMS收集器
- 垃圾回收器——CMS收集器
- CMS(Concurrent Mark Sweep)收集器
- Java CMS收集器
- CMS垃圾收集器
- CMS收集器
- CMS 收集器过程
- CMS垃圾收集器
- CMS垃圾收集器
- ICMP协议,ping和Traceroute 单独介绍
- 简单树的创建与遍历
- JFFS和YAFFS文件系统
- Spark实战-Spark SQL(三)
- 码农小汪-Hibernate学习1-Start of Hibernate
- JVMGC——并发收集器(CMS)
- Spark Streaming实战(一)
- python filter, map, reduce, lamda
- smarty模板引擎_10-Smarty模板的缓存
- Spark Streaming实战(二)
- Virtio 基本概念和设备操作(zz)
- Day01:
- Halcon OCR 字符训练识别
- ZMY_ImageLoader加载图片