一个有意思的CMS问题

简书 占小狼 转载请注明原创出处,谢谢!

大家新年好,愿你们在新的一年顺利晋升、工资涨涨涨...

之前无意间碰到一个有趣的CMS GC问题,问题很简单,现象很粗暴。

代码

/**
 * -Xmx20m -Xms20m -Xmn10m -XX:+UseParNewGC  -XX:+UseConcMarkSweepGC
 * -XX:+UseCMSInitiatingOccupancyOnly  -XX:CMSInitiatingOccupancyFraction=75
 * -XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:+PrintHeapAtGC
 */
public class JVM {

    private static final int _1MB = 1024 * 1024;

    public static void main(String[] args) throws Exception {

        byte[] b1 = new byte[2 * _1MB];
        byte[] b2 = new byte[2 * _1MB];
        byte[] b3 = new byte[2 * _1MB];
        byte[] b4 = new byte[4 * _1MB];
        System.in.read();
    }
}

现象

程序运行之后,执行jstat -gcutils pid 1000命令,结果如下:

在JVM参数中已经设置了-XX:+UseCMSInitiatingOccupancyOnly-XX:CMSInitiatingOccupancyFraction=75

只有在老年代的使用率达到75%时才会触发CMS回收,可目前的现象是老年代使用率才60%,就开始不停的GC、不停的GC、不停的GC,GC日志如下:

看这架势,应该是在不停的发生CMS GC了。

原因查找

既然一直在触发CMS,那问题根本因为在触发CMS的条件中,之前以为只要设置了-XX:+UseCMSInitiatingOccupancyOnly参数,只有在老年代的使用率达到阈值时才会触发。

翻了代码之后才发现,问题没这么简单,触发CMS的判断逻辑位于CMSCollector::shouldConcurrentCollect()方法中,实现如下:

在设置了-XX:+UseCMSInitiatingOccupancyOnly参数的前提下,有三种情况会触发:
1、老年代当前使用率是否达到阈值CMSInitiatingOccupancyFraction;
2、判断当前新生代的对象是否能够全部顺利的晋升到老年代,如果不能,就提早触发一次老年代的收集,这是本案例中不停CMS的根本原因,incremental_collection_will_fail(true)实现如下:

其中get_gen(0)指向当前年轻代的堆,因为设置了-XX:+UseParNewGC,则年轻代的堆实现是ParNewGeneration,该类继承了DefNewGeneration,方法collection_attempt_is_safe()位于DefNewGeneration类中,实现如下:

前面2个条件先忽略,看最后一个条件,_next_gen指向老年代的堆,其中promotion_attempt_is_safe()实现如下:

传入的参数max_promotion_in_bytes,由年轻代的used方法计算得到,eden区的使用量 + from区的使用量

size_t DefNewGeneration::used() const {
  return eden()->used()
       + from()->used();      // to() is only used during scavenge
}

其中promotion_attempt_is_safe()方法中的变量
1、available是老年代的可用内存大小
2、av_promo每次YGC时晋升到老年代对象大小的平均值

当老年代的可用内存大于av_promo,或者大于max_promotion_in_bytes时,说明下次的YGC是安全的,否则返回fasle,提早进行一次CMS操作,释放老年代的空间,以容纳下次YGC晋升上来的对象。

到这里,本文中的例子不断的进行CMS GC的疑惑应该可以解释清楚了。

别忘了,还有第三种情况:

if (CMSClassUnloadingEnabled && _permGen->should_concurrent_collect()) {
    bool res = update_should_unload_classes();
    if (res) {
      if (Verbose && PrintGCDetails) {
        gclog_or_tty->print_cr("CMS perm gen initiated");
      }
      return true;
    }
  }

前提是设置了-XX:+CMSClassUnloadingEnabled,而且_permGen永久带的内存使用率达到了阈值CMSInitiatingPermOccupancyFraction,默认值是92。

即使满足上面2个条件,还需要一层判断update_should_unload_classes()

如果一开始永久代大小没有设置、或者设置的很小,很有可能一开始就执行CMS,这让很多同学表示怀疑,什么都没做,就给我来一次CMS的日志。

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 158,560评论 4 361
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 67,104评论 1 291
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 108,297评论 0 243
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 43,869评论 0 204
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 52,275评论 3 287
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 40,563评论 1 216
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 31,833评论 2 312
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 30,543评论 0 197
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 34,245评论 1 241
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 30,512评论 2 244
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 32,011评论 1 258
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 28,359评论 2 253
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 33,006评论 3 235
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 26,062评论 0 8
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 26,825评论 0 194
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 35,590评论 2 273
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 35,501评论 2 268

推荐阅读更多精彩内容