性能文章>一个关于 Java 的堆内存的小探索>

一个关于 Java 的堆内存的小探索转载

1年前
278344

本文重在看一下探索思路,开始吧~

我们可以通过 -Xmx 或者 -XX:MaxHeapSize 来指定最大堆内存。如果不指定,它的默认值取决于物理内存大小,通常是 1/4。

物理内存大小是多大呢?如果遇到了容器会怎么样呢?我们先来做几个实验。

准备一台 8G 物理内存的宿主机,上面启动 512M 内存限制的 docker 容器,分别用不同的 JDK8 小版本进行默认堆内存大小的验证。

我们可以看到,OpenJDK8u111 是 1.73G,这一定是基于宿主机内存大小。

OpenJDK8u131 也是 1.73G,仍然是基于宿主机内存大小。不过如果增加了 UseCGroupMemoryLimitForHeap 参数,则变成了 114M,可以猜测这应该是基于容器的 512M 内存大小。

而到了 OpenJDK8u222,即使不加刚刚的参数,也是 123.75M,可以猜测仍然是基于容器的 512M 内存大小。

可以得出结论,不同的 JDK8 小版本对 "物理内存" 的获取是不同的,早期版本会获取到宿主机物理内存,后期版本会获取到容器的物理内存,中间的版本需要增加额外参数才会获取到容器的物理内存。

------

为什么会这样呢?论证起来很简单,只需要看下 111、131、222 这三个版本在获取物理内存的地方,都做了哪写手脚,有哪些改变,即可。

先看 OpenJDK8u111 源码,设置堆内存大小的代码在这里。

arguments.cpp

跟进发现是使用 Linux 的 physical_memory 获取物理内存。

继续跟进发现就是使用 sysconf 来获取 _SC_PHYS_PAGES 和 _SC_PAGESIZE 属性值,相乘即可。sysconf 不知道的可以 man 一下。

------

再看 OpenJDK8u131 源码,这个是加了参数就能获取到容器物理内存,我们看看咋弄的。

很直观,多了个判断分支,如果指定了这个参数,那么就读取一个 cgroup 下的文件,从里面取出 cgroup_max 的值,最后和宿主机物理内存取个较小值。

这就是所谓的支持容器化,就是多读了个文件,然后取较小值即可。

------

最后再看 OpenJDK8u222 源码,为什么它啥参数都不加,也能默认获取到的是容器的物理内存值呢?

set_heap_size 函数并没有发生变化,那么一定是 os::physical_memory 做了手脚。

可以看出,原来的 Linux::physical_memory 被挤到了下面,上面多了个 if 条件判断,如果是容器化,那么就读另一个文件获取内存大小。

------

可以看出,在 111 版本只有 os::physical_memory 这一种途径,来获取宿主机的物理内存。

在后来的 131 版本增加了个 if 条件,判断如果指定了某个参数,就取读取 cgroup 下的文件来获取物理内存。

而再后来的 222 版本,直接改造了 os::physical_memory 方法内部,使其判断如果是容器化,则读取 cgroup 下的文件来获取物理内存。

而如果把 os::physical_memory 方法继续跟进,你会发现它最终也是读取 /proc/meminfo 这个文件来提取数据而已。

所以,JDK 堆内存初始化的时候,物理内存的获取到底有没有支持容器化,这句话背后其实就是到底读哪个文件而已,只读 meminfo 文件就没支持容器化,既读 cgroup 文件又读 meminfo 文件就是支持容器化,就这么简单的事情。

------

这里继续强调底层重要性,关于这个问题你也会搜到好多文章讲,神乎其神的,而且做各种毫无意义的实验,但就是不肯再深入一步看看源码。

你觉得看源码难,但这个问题你一旦从源码的角度来看,就简单得要命,就是一个 if else 判断 + 读不同的文件提取数据,仅此而已。

而且你看源码,也能得出一些网上博客中没有体现的细节。

比如说 JDK 支持容器化的版本获取的物理内存就是容器的物理内存,这句就不完全正确,实际上时获取宿主机和容器的物理内存然后取个较小值。

再比如新版本的获取容器物理内存时,不再是读取一个固定的路径,而是通过读取 filesystems 后解析字符串提取出路径,这就更加灵活了。

看,这解析字符串是不是很恶心?稍稍变化一下格式这里就不兼容了,这些底层的东西也没那么神秘嘛~

好啦,一个小探索,分享给大家,希望大家以后面对问题时,能直接找到根因,而不是到处找资料,一头雾水。

 

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