在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数据是可变的，而其余部分应该对大多数应用程序保持静态。此