`
jveqi
  • 浏览: 319514 次
  • 性别: Icon_minigender_1
  • 来自: 北京
社区版块
存档分类
最新评论

JVM调优——之CMS 常见参数解析

 
阅读更多

JVM调优——之CMS 常见参数解析

   最近在学习使用CMS这个GC,这里记录下常用的参数。

1. UseCMSCompactAtFullCollection 与 CMSFullGCsBeforeCompaction

     有一点需要注意的是:CMS并发GC不是“full GC”。HotSpot VM里对concurrent collection和full collection有明确的区分。所有带有“FullCollection”字样的VM参数都是跟真正的full GC相关,而跟CMS并发GC无关的。
CMSFullGCsBeforeCompaction这个参数在HotSpot VM里是这样声明的:       

product(bool, UseCMSCompactAtFullCollection, true,                     \
        "Use mark sweep compact at full collections")                  \
                                                                       \
product(uintx, CMSFullGCsBeforeCompaction, 0,                          \
        "Number of CMS full collection done before compaction if > 0") \

然后这样使用的:

  *should_compact =
    UseCMSCompactAtFullCollection &&
    ((_full_gcs_since_conc_gc >= CMSFullGCsBeforeCompaction) ||
     GCCause::is_user_requested_gc(gch->gc_cause()) ||
     gch->incremental_collection_will_fail(true /* consult_young */));


CMS GC要决定是否在full GC时做压缩,会依赖几个条件。其中,
第一种条件,UseCMSCompactAtFullCollection 与 CMSFullGCsBeforeCompaction 是搭配使用的;前者目前默认就是true了,也就是关键在后者上。
第二种条件是用户调用了System.gc(),而且DisableExplicitGC没有开启。
第三种条件是young gen报告接下来如果做增量收集会失败;简单来说也就是young gen预计old gen没有足够空间来容纳下次young GC晋升的对象。
上述三种条件的任意一种成立都会让CMS决定这次做full GC时要做压缩。

CMSFullGCsBeforeCompaction 说的是,在上一次CMS并发GC执行过后,到底还要再执行多少次full GC才会做压缩。默认是0,也就是在默认配置下每次CMS GC顶不住了而要转入full GC的时候都会做压缩。 把CMSFullGCsBeforeCompaction配置为10,就会让上面说的第一个条件变成每隔10次真正的full GC才做一次压缩(而不是每10次CMS并发GC就做一次压缩,目前VM里没有这样的参数)。这会使full GC更少做压缩,也就更容易使CMS的old gen受碎片化问题的困扰。 本来这个参数就是用来配置降低full GC压缩的频率,以期减少某些full GC的暂停时间。CMS回退到full GC时用的算法是mark-sweep-compact,但compaction是可选的,不做的话碎片化会严重些但这次full GC的暂停时间会短些;这是个取舍。

2. -XX:CMSInitiatingOccupancyFraction=70 和-XX:+UseCMSInitiatingOccupancyOnly

    这两个设置一般配合使用,一般用于『降低CMS GC频率或者增加频率、减少GC时长』的需求

   -XX:CMSInitiatingOccupancyFraction=70 是指设定CMS在对内存占用率达到70%的时候开始GC(因为CMS会有浮动垃圾,所以一般都较早启动GC);

   -XX:+UseCMSInitiatingOccupancyOnly 只是用设定的回收阈值(上面指定的70%),如果不指定,JVM仅在第一次使用设定值,后续则自动调整.

3. -XX:+CMSScavengeBeforeRemark

   在CMS GC前启动一次ygc,目的在于减少old gen对ygc gen的引用,降低remark时的开销-----一般CMS的GC耗时 80%都在remark阶段

分享到:
评论

相关推荐

    jvm参数调优-jvmSample.zip

    《JVM参数调优——深度解析与实践指南》 在Java开发中,JVM(Java Virtual Machine)扮演着至关重要的角色。它不仅负责执行Java代码,还管理内存、线程等资源,确保程序的高效运行。然而,如果不合理地配置JVM参数...

    实战Java虚拟机——JVM故障诊断与性能优化.pdf

    《实战Java虚拟机——JVM故障诊断与性能优化》是一本深入探讨Java开发中的关键环节——Java虚拟机(JVM)的专著。本书聚焦于实际应用中的问题解决和性能调优,对于Java开发者和系统管理员来说,是提升技术水平的重要...

    30+个视频+深入理解Java虚拟机(jvm优化+内存模型+虚拟机原理)

    JVM提供了一套自动内存管理系统——垃圾回收器(Garbage Collector),用于跟踪不再使用的对象并释放其占用的内存空间。常见的垃圾回收算法包括标记-清除算法、复制算法、标记-整理算法等。不同版本的JVM可能会采用...

    Sun JDK 1.6内存管理--调优篇

    《Sun JDK 1.6内存管理--调优篇》深入探讨了Java开发中的关键环节——JVM内存管理和性能优化。Sun JDK 1.6作为早期的Java开发环境,其内存管理机制对于理解现代JVM的工作原理至关重要。本文将详细解析JVM内存结构,...

    JVM虚拟机源码(C++)

    5. **性能监控和调优**:HotSpot提供了丰富的性能监控工具,如JConsole、VisualVM等,源码中包含了这些工具的实现和与JVM交互的接口。 深入学习这份源码,你可以了解到: - **字节码执行**:JVM如何解析和执行字节...

    深入JVM内核—原理、诊断与优化视频教程-4.GC算法与种类

    在Java世界中,JVM(Java虚拟机)是运行所有Java应用程序的核心,它负责解析字节码、管理内存以及执行线程。本教程——“深入JVM内核—原理、诊断与优化视频教程”着重讲解了JVM的内部机制,特别是关于垃圾收集...

    java虚拟机源码-JVMbookSource:实战Java虚拟机———JVM故障诊断与性能优化(第2版)源码.rar

    《实战Java虚拟机——JVM故障诊断与性能优化(第2版)》是Java开发者深入理解JVM工作原理、诊断问题以及进行性能调优的重要参考资料。该书籍的源码提供了丰富的示例和实践案例,帮助读者更好地掌握Java虚拟机的内部...

    org.javacream.training.jvm

    五、JVM调优 `org.javacream.training.jvm`提供了调优实践,涵盖了JVM参数设置、性能监控工具(如JConsole、VisualVM)的使用,以及如何分析和解决性能瓶颈。通过实践,开发者能学会如何调整JVM参数以优化应用程序...

    hotspot实战

    《HotSpot实战》一书深入探讨了Java Virtual Machine (JVM) 的一个重要实现——HotSpot。HotSpot是Oracle公司开发的高性能JVM,它在Java应用程序的运行时提供了一个优化的平台。本书针对HotSpot JVM的内部工作原理、...

    《HotSpot实战》

    1. **Java虚拟机概述**:HotSpot是基于Java虚拟机(JVM)的实现,它负责解析和执行Java字节码,为开发者提供跨平台的运行环境。HotSpot的主要任务包括内存管理、垃圾收集、类加载、线程管理和性能优化。 2. **...

    openjdk源码3

    《OpenJDK源码探索——深入理解Java运行机制》 OpenJDK,全称为Open Source Java Development Kit,是Java开发工具集的一个开源实现,由Oracle公司主导并维护,旨在为Java开发者提供一个开放、免费的平台来研究和...

Global site tag (gtag.js) - Google Analytics