首页
学习
活动
专区
工具
TVP
发布
精选内容/技术社群/优惠产品,尽在小程序
立即前往

为什么CMS结束语中的ParNew,sys时间这么长?

CMS(Concurrent Mark Sweep)是一种用于垃圾回收的Java虚拟机的收集器。在CMS结束语中,ParNew和sys时间长的原因可能有以下几点:

  1. ParNew是CMS收集器的新生代收集器,负责回收年轻代的垃圾对象。由于年轻代通常包含大量的短命对象,因此ParNew的回收频率较高,可能导致sys时间较长。
  2. sys时间指的是操作系统级别的时间,包括系统调用、内核操作等。在CMS结束语中,sys时间长可能是由于操作系统负载较高、资源竞争等原因导致的。
  3. CMS收集器是一种并发收集器,它在垃圾回收过程中与应用程序并发执行。这意味着CMS需要与应用程序竞争系统资源,可能导致sys时间较长。
  4. CMS收集器的特点是以获取最短回收停顿时间为目标,因此在回收过程中会尽量减少应用程序的停顿时间。为了达到这个目标,CMS采用了一些优化策略,如并发标记、并发清除等。这些策略可能会增加sys时间。

针对CMS结束语中ParNew和sys时间长的情况,可以考虑以下优化措施:

  1. 调整垃圾回收参数:可以根据具体情况调整CMS收集器的参数,如调整新生代大小、调整并发线程数等,以优化回收性能。
  2. 优化应用程序:可以对应用程序进行性能优化,减少垃圾对象的产生,降低垃圾回收的压力。
  3. 资源调整:如果sys时间长是由于系统资源竞争导致的,可以考虑增加系统资源,如CPU、内存等,以提高系统的处理能力。

腾讯云提供了一系列与云计算相关的产品,如云服务器、云数据库、云存储等。具体针对CMS结束语中的问题,腾讯云并没有直接相关的产品或文档可以推荐。但腾讯云的云服务器和云数据库等产品可以提供稳定的计算和存储资源,以支持应用程序的运行和数据存储。您可以访问腾讯云官方网站(https://cloud.tencent.com/)了解更多关于腾讯云产品的信息。

页面内容是否对你有帮助?
有帮助
没帮助

相关·内容

什么叫杂谈(e网杂谈)

这篇文章的起因是这样的,在上周五凌晨很苦逼得参加双十一压测值班的时候,有个业务方突然打电话来说我们提供的客户端存在内存泄漏问题导致线上应用持续full gc,本来已经快要睡着的我立马就精神起来了,一通排查,最终定位到了确实是客户端有个bug会导致部分数据会被一直持有进入老年代之后gc不掉,从而就导致了老年代的频繁gc,具体bug暂且不表,有一个很奇怪的现象引起了我的注意,那就是从监控系统上来看,这个应用平均一分钟full gc次数高达十多次,按照我之前的理解full gc时是会stop the world的,stop the world的频率这么高,那么应用自身的服务已经跪掉了啊,但是看这个应用的业务指标监控,居然一切正常,这就有点超出我的理解能力了,后面为了解决这个疑问,针对什么是full gc,以及如何查看full gc的次数等查阅了很多资料,总算搞懂了full gc这个概念,在查资料的过程中发现中文社区里面包含太多错误的信息了,而且大多都是抄来抄去的,非常误导人,因此打算写一篇文章,对一些错误观点进行纠正。

02
  • 深入理解java虚拟机学习笔记(二)-jvm垃圾收集器和内存分配策略

    对于大多数语言中判断对象是否存活会采用引用计数法:给对象添加一个引用计数器,当有一个地方引用时,计数器就加1,当引用失效时,计数器就减1。任何时刻只要计数器为0则回收。但是这种算法无法解决对象之间互相循环引用的问题。如A引用B,而B又引用A,计数器永远不为0,这两个对象再也无任何引用。这样GC不能回收这两个对象。 因此,在JAVA中,采用了可达性分析算法来解决这个问题,判断对象是否存活。 可达性分析算法:通过GCRoots的对象作为起点,从这些节点向下搜索,搜索走过的路径称之为引用链(Reference Chain),当一个对象到达GCRoots没有任何链相连,则证明此对象不可用,可以被GC回收。

    02
    领券