正文
![]()
Java和Docker不是天然的朋友。 Docker可以设置内存和CPU限制，而Java不能自动检测到。使用Java的Xmx标识（繁琐/重复）或新的实验性JVM标识，我们可以解决这个问题。
Java和Docker的结合并不是完美匹配的，最初的时候离完美匹配有相当大的距离。对于初学者来说，JVM的全部设想就是，虚拟机可以让程序与底层硬件无关。
那么，把我们的Java应用打包到JVM中，然后整个再塞进Docker容器中，能给我们带来什么好处呢？大多数情况下，你只是在复制JVMs和Linux容器，除了浪费更多的内存，没任何好处。感觉这样子挺傻的。
不过，Docker可以把你的程序，设置，特定的JDK，Linux设置和应用服务器，还有其他工具打包在一起，当做一个东西。站在DevOps/Cloud的角度来看，这样一个完整的容器有着更高层次的封装。
时至今日，绝大多数产品级应用仍然在使用Java 8（或者更旧的版本），而这可能会带来问题。Java 8（update 131之前的版本）跟Docker无法很好地一起工作。问题是在你的机器上，JVM的可用内存和CPU数量并不是Docker允许你使用的可用内存和CPU数量。
比如，如果你限制了你的Docker容器只能使用100MB内存，但是呢，旧版本的Java并不能识别这个限制。Java看不到这个限制。JVM会要求更多内存，而且远超这个限制。如果使用太多内存，Docker将采取行动并杀死容器内的进程！JAVA进程被干掉了，很明显，这并不是我们想要的。
为了解决这个问题，你需要给Java指定一个最大内存限制。在旧版本的Java（8u131之前），你需要在容器中通过设置-Xmx来限制堆大小。这感觉不太对，你可不想定义这些限制两次，也不太想在你的容器中来定义。
幸运的是我们现在有了更好的方式来解决这个问题。从Java 9之后（8u131+），JVM增加了如下标志：
-XX:+UnlockExperimentalVMOptions -XX:+UseCGroupMemoryLimitForHeap
这些标志强制JVM检查Linux的cgroup配置，Docker是通过cgroup来实现最大内存设置的。现在，如果你的应用到达了Docker设置的限制（比如500MB），JVM是可以看到这个限制的。JVM将会尝试GC操作。如果仍然超过内存限制，JVM就会做它该做的事情，抛出OutOfMemoryException。也就是说，JVM能够看到Docker的这些设置。
从Java 10之后（参考下面的测试），这些体验标志位是默认开启的，也可以使用-XX:+UseContainerSupport来使能（你可以通过设置-XX:-UseContainerSupport来禁止这些行为）。
第二个问题是类似的，但它与CPU有关。简而言之，JVM将查看硬件并检测CPU的数量。它会优化你的runtime以使用这些CPUs。但是同样的情况，这里还有另一个不匹配，Docker可能不允许你使用所有这些CPUs。可惜的是，这在Java 8或Java 9中并没有修复，但是在Java 10中得到了解决。
从Java 10开始，可用的CPUs的计算将采用以不同的方式（默认情况下）解决此问题（同样是通过UseContainerSupport）。
作为一个有趣的练习，让我们验证并测试Docker如何使用几个不同的JVM版本/标志甚至不同的JVM来处理内存不足。
首先，我们创建一个测试应用程序，它只是简单地“吃”内存并且不释放它。
javaimport java.util.ArrayList;import java.util.List;public class MemEat { public static void main(String[] args) { List l = new ArrayList<>(); while (true) { byte b[] = new byte[1048576]; l.add(b); Runtime rt = Runtime.getRuntime(); System.out.println( "free memory: " + rt.freeMemory() ); } }}
我们可以启动Docker容器并运行这个应用程序来查看会发生什么。
首先，我们将从具有旧版本Java 8的容器开始（update 111）。
shelldocker run -m 100m -it java:openjdk-8u111 /bin/bash
shelljavac MemEat.javajava MemEat...free memory: 67194416free memory: 66145824free memory: 65097232Killed
正如所料，Docker已经杀死了我们的Java进程。不是我们想要的（！）。你也可以看到输出，Java认为它仍然有大量的内存需要分配。
我们可以通过使用-Xmx标志为Java提供最大内存来解决此问题：
shelljavac MemEat.javajava -Xmx100m MemEat...free memory: 1155664free memory: 1679936free memory: 2204208free memory: 1315752Exception in thread "main" java.lang.OutOfMemoryError: Java heap space at MemEat.main(MemEat.java:8)
在提供了我们自己的内存限制之后，进程正常停止，JVM理解它正在运行的限制。然而，问题在于你现在将这些内存限制设置了两次，Docker一次，JVM一次。
如前所述，随着增加新标志来修复问题，JVM现在可以遵循Docker所提供的设置。我们可以使用版本新一点的JVM来测试它。
shelldocker run -m 100m -it adoptopenjdk/openjdk8 /bin/bash
（在撰写本文时，此OpenJDK Java镜像的版本是Java 8u144）
接下来，我们再次编译并运行MemEat.java文件，不带任何标志：
shelljavac MemEat.javajava MemEat...free memory: 67194416free memory: 66145824free memory: 65097232Killed
依然存在同样的问题。但是我们现在可以提供上面提到的实验性标志来试试看：
shelljavac MemEat.javajava -XX:+UnlockExperimentalVMOptions -XX:+UseCGroupMemoryLimitForHeap MemEat...free memory: 1679936free memory: 2204208free memory: 1155616free memory: 1155600Exception in thread "main" java.lang.OutOfMemoryError: Java heap space at MemEat.main(MemEat.java:8)
这一次我们没有告诉JVM限制的是什么，我们只是告诉JVM去检查正确的限制设置！现在感觉好多了。
有些人在评论和Reddit上提到Java 10通过使实验标志成为新的默认值来解决所有问题。这种行为可以通过禁用此标志来关闭：-XX：-UseContainerSupport。
当我测试它时，它最初不起作用。在撰写本文时，AdoptAJDK OpenJDK10镜像与jdk-10+23一起打包。这个JVM显然还是不理解UseContainerSupport标志，该进程仍然被Docker杀死。
shelldocker run -m 100m -it adoptopenjdk/openjdk10 /bin/bash
shelljavac MemEat.javajava MemEat...free memory: 96262112free memory: 94164960free memory: 92067808free memory: 89970656Killedjava -XX:+UseContainerSupport MemEatUnrecognized VM option 'UseContainerSupport'Error: Could not create the Java Virtual Machine.Error: A fatal exception has occurred. Program will exit.
我决定尝试AdoptAJDK OpenJDK 10的最新nightly构建。它包含的版本是Java 10+46，而不是Java 10+23。
