性能文章>CMS GC 新生代默认是多大?>

CMS GC 新生代默认是多大?原创

2年前
7027212

问题

首先抛个问题给大家,看下面 JVM 参数配置:

-Xmx2g -Xms2g -XX:+UseConcMarkSweepGC

猜一猜按照这样的 JVM 参数配置,YoungGen(新生代)是多大呢?
你一定会觉得这还不简单吗,NewRatio 默认为 2,也就是 YoungGen 与 OldGen(老年代)的比例是 1:2,那 YoungGen 大小应该是 2048M/3 = 672M。
真的是这样吗?jmap -heap pid 看看

image.png

然而结果居然是 332.75M(说明下案例中的 JDK 版本是 7)。

分析

要想知道原因,只能撸源码了。
我们从 Arguments(是用来解析 JVM 参数)类的 setcmsandparnewgc_flags 函数说起,看函数名也知道是对 CMS 和 ParNew GC 的参数设置。

image.png

看提示 1,在 MaxNewSize 和 NewRatio 都是默认配置时,MaxNewSize 值为 preferredmaxnewsize,而 preferredmaxnewsize 是什么呢?
看提示 2,alignsizeup 主要是字节对齐用的,可以不用关系细节,所以 preferredmaxnewsize 主要取决于 preferredmaxnewsizeunaligned,
再看提示 3,preferredmaxnewsize_unaligned 的值为

MIN2(max_heap/(NewRatio+1), ScaleForWordSize(young_gen_per_worker * parallel_gc_threads))

也就是取 maxheap/(NewRatio+1) 和 ScaleForWordSize(younggenperworker * parallelgcthreads) 中较小的那个,max_heap/(NewRatio+1) 这个我们都了解,就是按照 NewRatio 来计算,ScaleForWordSize 又是什么呢?我们来看下 ScaleForWordSize 的定义:

image.png

因为这里我们是 64 位的机器,所以看上面的那行,alignsizedown_ 这个也是字节对齐的,所以 ScaleForWordSize 返回值约为 (x) * 13 / 10,也就是 younggenperworker * parallelgcthreads * 13 / 10 。因此,我们再看看 younggenperworker 和 parallelgcthreads 的取值,而 younggenperworker = CMSYoungGenPerWorker,
CMSYoungGenPerWorker 在另一块代码中有定义,跟硬件相关,x86 机器为 64M;而 parallelgcthreads 的值呢?
parallelgc_threads = (ParallelGCThreads == 0 ? 1 : ParallelGCThreads),所以我们得看 ParallelGCThreads 的设置

image.png

可知,ParallelGCThreads 在没有设置的情况下会设置成 parallelworkerthreads 函数返回值,我们接着看 parallelworkerthreads 函数:

image.png

再看 calcparallelworker_threads 函数:

image.png

在看 nofparallelworker_threads 函数:

image.png

根据上面三个函数,ParallelGCThreads 最终由 nofparallelworker_threads 函数计算出,其中 ncpus 是 cpu 的核数,测试机器是 4 核,所以 ncpus 为 4,按照上面的公式计算,因此, ParallelGCThreads 为 4。

所以绕了半天,ScaleForWordSize 的值大约是 64M * 4 * 13 / 10 = 332.8M,再做下对齐就得到 332.75M 了;max_heap / (NewRatio+1) 的值为2048M / 3 = 672M,而新生代的值取了较小的 ScaleForWordSize,故为 332.75M。

总结

看到上面的过程,是不是有点奔溃。YoungGen 的大小在没有设置的情况下是通过计算得出的,其大小可能与 NewRatio 的默认配置没什么关系而与ParallelGCThreads 的配置有一定的关系。
那么既然 YoungGen 大小有不确定性,我们最好还是通过这些 -XX:NewSize、-XX:MaxNewSize 或者 -xmn 参数设置下,免得遇到一些奇怪的 GC,让你措手不及。

分类:标签:
请先登录,查看2条精彩评论吧
快去登录吧,你将获得
  • 浏览更多精彩评论
  • 和开发者讨论交流,共同进步

为你推荐

不起眼,但是足以让你有收获的JVM内存分析案例
分析 这个问题说白了,就是说有些int[]对象不知道是哪里来的,于是我拿他的例子跑了跑,好像还真有这么回事。点该 dump 文件详情,查看相关的 int[] 数组,点该对象的“被引用对象”,发现所
从一起GC血案谈到反射原理
前言 首先回答一下提问者的问题。这主要是由于存在大量反射而产生的临时类加载器和 ASM 临时生成的类,这些类会被保留在 Metaspace,一旦 Metaspace 即将满的时候,就会触发 Fu
关于内存溢出,咱再聊点有意思的?
概述 上篇文章讲了JVM在GC上的一个设计缺陷,揪出一个导致GC慢慢变长的JVM设计缺陷,可能有不少人还是没怎么看明白的,今天准备讲的大家应该都很容易看明白 本文其实很犹豫写不写,因为感觉没有
协助美团kafka团队定位到的一个JVM Crash问题
概述 有挺长一段时间没写技术文章了,正好这两天美团kafka团队有位小伙伴加了我微信,然后咨询了一个JVM crash的问题,大家对crash的问题都比较无奈,因为没有现场,信息量不多,碰到这类问题我
又发现一个导致JVM物理内存消耗大的Bug(已提交Patch)
概述 最近我们公司在帮一个客户查一个JVM的问题(JDK1.8.0_191-b12),发现一个系统老是被OS Kill掉,是内存泄露导致的。在查的过程中,阴差阳错地发现了JVM另外的一个Bug。这个B
JVM实战:优化我的IDEA GC
IDEA是个好东西,可以说是地球上最好的Java开发工具,但是偶尔也会卡顿,仔细想想IDEA也是Java开发的,会不会和GC有关,于是就有了接下来对IDEA的GC进行调优 IDEA默认JVM参数: -
不起眼,但是足以让你收获的JVM内存案例
今天的这个案例我觉得应该会让你涨姿势吧,不管你对JVM有多熟悉,看到这篇文章,应该还是会有点小惊讶的,不过我觉得这个案例我分享出来,是想表达不管多么奇怪的现象请一定要追究下去,会让你慢慢变得强大起来,
如何通过反射获得方法的真实参数名(以及扩展研究)
前段时间,在做一个小的工程时,遇到了需要通过反射获得方法真实参数名的场景,在这里我遇到了一些小小的问题,后来在部门老大的指导下,我解决了这个问题。通过解决这个问题,附带着我了解到了很多新的知识,我觉得