CMS 垃圾回收
来源:互联网 发布:新开的淘宝店怎么找货 编辑:程序博客网 时间:2024/06/10 04:12
http://blog.csdn.net/java2000_wl/article/details/8030172
先说并发
4.1并发意味着多线程抢占CPU资源,即GC线程与用户线程抢占CPU。这可能会造成用户线程执行效率下降。
CMS默认的回收线程数是(CPU个数+3)/4。这个公式的意思是当CPU大于4个时,保证回收线程占用至少25%的CPU资源,这样用户线程占用75%的CPU,这是可以接受的。
4.2 并发清理阶段用户线程还在运行,这段时间就可能产生新的垃圾,新的垃圾在此次GC无法清除,只能等到下次清理。这些垃圾有个专业名词:浮动垃圾。
由于垃圾回收阶段用户线程仍在执行,必需预留出内存空间给用户线程使用。因此不能像其他回收器那样,等到老年代满了再进行GC。
CMS 提供了CMSInitiatingOccupancyFraction参数来设置老年代空间使用百分比,达到百分比就进行垃圾回收。
这个参数默认是92%,参数选择需要看具体的应用场景。
设置的太小会导致频繁的CMS GC,产生大量的停顿;反过来想,设置的太高会发生什么?
假设现在设置为99%,还剩1%的空间可以使用。
在并发清理阶段,若用户线程需要使用的空间大于1%,就会产生Concurrent Mode Failure错误,意思就是说并发模式失败。
这时,虚拟机就会启动备案:使用Serial Old收集器重新对老年代进行垃圾回收.如此一来,停顿时间变得更长。
4.3 前两个问题是由并发引起的,接下来要说的问题就是由标记-清除算法引起的。
使用标记-清除算法可能造成大量的空间碎片。空间碎片过多,就会给大对象分配带来麻烦。
往往老年代还有很大剩余空间,但无法找到足够大的连续空间来分配当前对象,不得不触发一次Full GC。
CMS的解决方案是使用UseCMSCompactAtFullCollection参数(默认开启),在顶不住要进行Full GC时开启内存碎片整理。
这个过程需要STW,碎片问题解决了,但停顿时间又变长了。
虚拟机还提供了另外一个参数CMSFullGCsBeforeCompaction,用于设置执行多少次不压缩的Full GC后,跟着来一次带压缩的(默认为0,每次进入Full GC时都进行碎片整理)。
- CMS垃圾回收算法
- CMS垃圾回收器
- CMS垃圾回收器
- CMS垃圾回收过程
- CMS 垃圾回收
- CMS垃圾回收器
- cms垃圾回收
- CMS 垃圾回收
- JVM垃圾回收CMS
- 了解 CMS 垃圾回收日志
- cms垃圾回收算法心得
- 详解CMS垃圾回收机制
- CMS垃圾回收器详解
- java垃圾回收之CMS
- java垃圾回收机制--CMS
- CMS 垃圾回收算法总结
- 了解 CMS 垃圾回收日志
- 详解CMS垃圾回收机制
- 深入分析Http协议
- java 实现二分查找法
- 常用命令
- 【Android】Fragment+Viewpager实现底部导航栏(带小红点)
- 安全技术网站+开源网址
- CMS 垃圾回收
- 任意进制转换 python实现
- quartz springh和 spring-task 定时任务
- android下pthread相关概念理解
- Android XML布局文件解析过程源码解析
- sqlserver性能优化
- 泛类弄的声明
- PHP面试篇之基础0
- (CSU