https://zhuanlan.zhihu.com/p/61408911

在Logistimo，咱们的全部应用程序都是Docker化的，并在Kubernetes内以docker容器运行。咱们注意到在使用Java的容器上发生了大量重启，而且很是随机。Docker检查发现该pod被OOMKiller代码杀死：137。

这意味着应用程序消耗的内存比分配给容器的内存多。这听起来不对，由于咱们使用-Xmx对Java应用程序进行了限制，而且咱们为元空间和GC数据留下了大约20％的缓冲区做为Kubernetes资源限制（docker容器）。

例如，Java进程为2 GB，Kubernetes资源为2.4 GB。

后续部分将介绍此问题以及如何详细解决此问题。

 

JVM内存使用状况

第一步是检查容器超出上述限制的缘由，显然这些是被缓冲充分利用了。

使用“ps”命令能够确认Xmx确实就位，并设置为最大4GB。

可是，“top”命令显示使用的物理内存为4.5 GB。

 

为何Java会比分配多500 MB？

JDK 从1.8.40开始，引入了一个Native内存跟踪器工具，它提供了Java应用程序使用的内存的详细分解，并考虑了每一个字节。请注意，NMT工具显示已提交，驻留可能更少。

实际使用=堆内存+元空间+Off堆

Off heap一般由类元数据，编译代码，线程和GC数据组成。GC数据是可变的，而其他部分应该对大多数应用程序保持静态。此内存是本机的（是的，包括元空间），JVM使用主机上的可用内存来增加或垃圾收集此数据。

回到手头的问题，JVM占用了500 MB，由于底层主机有16 GB的存储空间。有时这个数字可能高于咱们设置的缓冲区，这将致使容器被终止。JVM不该该读取docker容器的内存限制吗？

 

容器和Java

事实证实，Java版本9及如下版本根本不了解容器/Docker（默认状况下）。它从底层主机中获取可用的CPU和内存。在容器内的主机上运行的每一个Java应用程序都依赖于主机配置。考虑到咱们是Kubernetes而且许多pod在单个节点上运行，这可能会致使咱们面临的问题。

Java 10支持开箱即用的容器，它将查找linux cgroup信息。这容许JVM基于容器限制进行垃圾收集。默认状况下使用标志打开它。

-XX:+UseContainerSupport

值得庆幸的是，其中一些功能已被移植到8u131和9之后。可使用如下标志打开它们。

-XX:+UnlockExperimentalVMOptions -XX:+UseCGroupMemoryLimitForHeap

 

总结

较旧版本的Java读取底层主机，而且不了解cgroup。这会致使容器配置和Java进程不匹配。这种不匹配在CPU和内存上。Java有一个Off堆内存组件，它有一个动态GC数据组件，能够增加。解决此问题的最佳方法是使用最新版Java中提供的容器支持功能。不要依赖缓冲（这是浪费钱）。

若是您必须继续使用这些主要版本并打开实验标志，请升级到Java 8u131 +或Java 9。更好的是，若是你能够得到Java 10以上将对全部容器有好处。