一个有趣又诡异的频繁CMS问题

本文通过一个具体的案例探讨了Java应用程序中出现频繁CMS垃圾回收的原因。尽管设置了特定的JVM参数来控制老年代的占用率阈值,但在实际运行过程中发现,老年代的使用率尚未达到设定的阈值便触发了CMS回收。文中详细分析了这一现象背后的原因,并提出了可能的解释。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >


         笔者在一个技术交流群里面看到一位朋友发了一个有趣又诡异的频繁CMS问题的程序,程序代码如下:


        


       

           设置的JVM参数如下:

          -Xmx20m -Xms20m -Xmn10m   -XX:+UseParNewGC  -XX:+UseConcMarkSweepGC  -XX:+UseCMSInitiatingOccupancyOnly
          -XX:CMSInitiatingOccupancyFraction=75


           运行程序,然后用jstat命令查看gc的情况如下:

           



                 下面是对该现象讲解一下我个人的思路:


                 明明JVM已经设置了-XX:+UseCMSInitiatingOccupancyOnly   -XX:CMSInitiatingOccupancyFraction=75这个参数,从gc情况来看,老年代内存使用率只有60.02%还没有达到75%这个阈值 但是却频繁发生CMS回收了 ,也就是说b1、b2、b3三个对象已经晋升到老年代了,b4先是分配到新生代,后面JVM为了把b4对象从新生代晋升到老年代提前触发了CMS回收,这也就是GC出现频繁CMS的原因了。


                   当然,以上只是我个人的观点,欢迎大家讲讲自己的看法

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值