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

我们可以通过 -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 后解析字符串提取出路径，这就更加灵活了。

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

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