在基于物理的服务器（此处主要与容器平台进行区分，故此描述）上运行Java应用程序时，我们通常会使用Java虚拟机参数"-Xms、-Xmx"来指定Java堆内存的初始值和最大值。如果要将我们的应用程序移植到容器平台，如何在容器环境中配置Java堆内存大小呢？有没有最佳做法？在本文中，我们将讨论可用于指定Java堆内存大小的JVM参数以及最优选择。
在我们的容器环境中，通常可借助以下3个不同的选项来指定容器中的Java堆内存的大小。 具体：
1、-XX:Min(Max)RAMFraction
2、-XX:Min(Max)RAMPercentage
3、-Xms、-Xmx
下面针对这些JVM参数，我们进行简要的解析：
1、-XX:Min(Max)RAMFraction
此参数“-XX:MinRAMFraction”、“-XX:MaxRAMFraction”支持JDK版本：目前仅支持的版本为Java 8 update 131 to Java 8 update 190。因此，如果使用的是其他版本的JDK，则不能使用此选项。
原理解析：
假设我们已为容器分配了1 GB的内存，那么如果配置-XX:MaxRAMFraction = 2，则将为Java堆大小分配大约512GB（即1GB的1/2）。
如果要使用“-XX:MaxRAMFraction” JVM参数，请确保传递这两个附加的JVM参数以及“ -XX:+UnlockExperimentalVMOptions与-XX:+UseCGroupMemoryLimitForHeap”。仅当我们配置这两个JVM参数时，JVM才会从容器的内存大小中得出堆内存大小值，否则，它将从基础主机的内存大小中得出堆大小值。
[administrator@JavaLangOutOfMemory ~ ]% docker run -m 1GB openjdk：8u131 java -XX:+UnlockExperimentalVMOptions -XX:+UseCGroupMemoryLimitForHeap -XX:MaxRAMFraction = 2 -XshowSettings：vm-版本VM设置：最高堆大小（估计）：494.94M
通过上面命令，我们可以看到docker容器的内存此时设置为“ 1GB ”（即-m 1GB）和“ -XX:MaxRAMFraction = 2 ”。基于此设置，JVM将最大堆大小分配为494.9MB（约为1GB大小的一半）。
注意：“ -XX:MaxRAMFraction”和“ -XX:MinRAMFraction”均用于确定最大Java堆大小。JDK开发团队可以使用比“ -XX:MinRAMFraction”更好的名称。这个名称使我们认为，“-XX：MinRAMFraction”参数用于配置最小堆大小。但这不是真的。要了解有关它们差异的更多信息，请继续阅读本文。
会有什么限制？以下为这种方法的缺陷：
1、假设我们配置docker内存大小的40％，则必须设置“ -XX:MaxRAMFraction = 2.5”。当传递2.5作为值时，JVM将不会启动。这是因为“ -XX:MaxRAMFraction”只能接受整数值，而不能接受十进制值。请参阅以下示例，其中JVM无法启动。
[administrator@JavaLangOutOfMemory ~ ]% docker run -m 1GB openjdk:8u131 java -XX:+UnlockExperimentalVMOptions -XX:+UseCGroupMemoryLimitForHeap -XX:MaxRAMFraction=2.5 -XshowSettings:vm -version VM Improperly specified VM option 'MaxRAMFraction=2.5' Improperly specified VM option 'MaxRAMFraction=2.5' Error: Could not create the Java Virtual Machine. Error: A fatal exception has occurred. Program will exit.
2、在此选项中，Java应用程序的堆大小将从容器的内存大小得出（因为它是分数基础）。假设如果我们的应用程序需要1GB的堆大小才能获得最佳性能，并且如果将容器配置为以小于1GB的内存大小运行，则我们的应用程序仍将运行，但是会遭受不良的性能特征。
3、在现代Java版本中不建议使用此参数。从Java 8 update 131 to Java 8 update 190仅受支持。
2、-XX：Min(Max)RAMPercentage
此参数“ -XX:MaxRAMPercentage”、“-XX:MinRAMPercentage”支持JDK版本：Java 8 update 191及更高。因此，如果在较早的JDK版本上运行，则不能使用此JVM参数。
原理解析：
假设我们已为容器分配了1 GB的内存，那么如果配置-XX:MaxRAMPercentage = 50，则将为我们的应用的Java堆大小分配大约512GB（即1GB的1/2）。
[administrator@JavaLangOutOfMemory ~ ]% docker run -m 1GB openjdk：10 java -XX:MaxRAMPercentage = 50 -XshowSettings:vm -version
此处，我们可以看到Docker容器的内存此时设置为-m 1GB和-XX:MaxRAMPercentage = 50。根据此参数配置，JVM将最大堆大小分配为494.9MB（大约1GB的一半）。
备注：网上有文章中，提到在传递“ -XX:MaxRAMPercentage”，“-XX:InitialRAMPercentage”，“-XX:MinRAMPercentage”时，需要传递JVM参数-XX。其实不是这样。JVM中的默认参数传递了“ -XX:+ UseContainerSupport”。因此，我们无需显式定义。
会有什么限制？以下为这种方法的缺陷：
1、Java的较早版本不支持此参数。仅Java 8更新191支持它。
2、在此选项中，我们的Java应用程序的堆大小将由容器的内存大小得出（因为它是基于百分比的）。假设我们的应用程序需要1GB的堆大小才能获得最佳性能，并且如果将容器配置为以小于1GB的内存大小运行，则您的应用程序仍将运行，但是性能会很差。
3. -Xmx
此参数支持所有的JDK版本。
原理解析：
使用“ -Xmx” 此类型的JVM参数，我们可以指定细粒度的特定大小，例如512MB，1024MB。
在非容器（传统物理服务器世界）环境下支持的-Xmx操作如下：
[administrator@JavaLangOutOfMemory ~ ]%java -Xmx512m -XshowSettings：vm -version
在容器环境下支持的-Xmx操作如下：
[administrator@JavaLangOutOfMemory ~ ]%docker run -m 1GB openjdk：8u131 java -Xmx512m -XshowSettings：vm -version VM
备注：如果分配的“-Xmx”多于容器的内存大小，则我们的应用程序将遇到“ java.lang.OutOfMemoryError：杀死进程或牺牲子进程” 等异常事件发生。
无论我们使用什么选项来配置堆大小（即-XX:MaxRAMFraction、-XX:MaxRAMPercentage、-Xmx），请始终确保为我们的容器（即-m）分配的内存至少多25％堆大小值。假设我们已将-Xmx值配置为2GB，然后将容器的内存大小至少配置为2.5GB。即使我们的Java应用程序是将在容器上运行的唯一进程，也要执行此操作。因为许多工程师认为Java应用程序消耗的值不会超过-Xmx值。那是不对的。除了堆空间，应用程序还需要Java线程，垃圾回收，元空间，本机内存和套接字缓冲区的空间。所有这些组件都需要分配的堆大小之外的其他内存。除此之外，其他小型进程（例如APM代理，splunk脚本等）也将需要内存。
如果仅在容器中运行Java应用程序，则将初始堆大小设置为与最大堆相同的大小值（即，使用“ -XX:InitialRAMFraction”、“-XX:InitialRAMPercentage”、“-Xms”）。设置初始堆大小和最大堆值相同具有某些优点。其中之一是：将减少垃圾收集的暂停时间。因为只要堆大小从初始分配的大小增加，它就会暂停JVM。当将初始堆大小和最大堆大小设置为相同时，可以避免这种情况。除此之外，如果我们没有分配的容器的内存大小，那么JVM甚至不会启动（这比在进行事务处理时遇到OutOfMemoryError更好）。
在我看来，我倾向于使用-Xmx选项而不是-XX:MaxRAMFraction、-XX:MaxRAMPercentage选项来指定容器世界中的Java堆大小，原因如下：内存大小是决定应用程序性能的关键。它影响垃圾收集行为和性能特征，不希望该因素由容器的内存设置决定。
使用“ -Xmx”，我可以设置512MB，256MB等细粒度/精度值。加之，-Xmx在所有Java版本上均受支持。
