短短几年，容器就改变了软件行业的开发模式。也许，很多开发者已经开始在容器中运行Java应用。但是，对于容器化的Java应用程序，当遇到CPU和内存占用等问题时，还是有很多问题需要注意。本文假设读者对Java和容器技术有基本了解，如果需要更多背景知识，可以阅读文末的参考文献。

堆空间

如果说在容器中运行Java应用有一条核心定律，那么就是：对于在容器中运行的Java进程，不要手工设置JVM堆内存。相反的，设置容器的限制。

为什么？

首先，设置容器的限制可以实现容器/cgroup提供的基本功能，既隔离容器内进程的资源使用。当我们通过JVM参数手工设置堆内存的时候，就意味着彻底无视这个功能。这样能够方便的调整容器资源分配，为自动化扩缩容容器（例如K8s垂直pod自动扩缩容）打开了大门，而无需手工调整JVM参数。

如果容器运行在编排引擎环境中（例如Kubernetes），那么容器的限制对于节点健康度和调度都非常重要。调度器需要使用这些限制来找到适合容器运行的节点，同时确保节点之间负载均衡。如果通过JVM参数设置内存使用，这个信息无法通知到调度器，因此调度器无法知道如何为容器分配负载。

如果不设置容器限制，同时运行在容器中的Java进程也没有显式设置JVM内存参数，那么JVM将会自动设置最大堆内存为运行节点总内存的25%。例如，如果容器运行在一个内存为64GB的节点上，JVM进程堆内存最大可设置成16GB。如果这个节点上运行了10个容器（对于自动扩缩容经常发生），那么可能会突然需要160G内存。

我们能做什么？

设置容器内存（和CPU）限制，依赖资源请求（软限制）是不够的。资源请求对调度器非常有用，但是设置硬限制让Docker（或者其他容器运行时环境）为容器分配指定资源，同时确保不会超出。这也让Java（在Java 8u191之后，默认提供“容器感知”功能）基于容器设置的资源限制自动分配内存，而不是通过运行节点分配。

关于[Min|Max|Initial]RAMPercentage参数

最近的Java版本中，引入了如下JVM参数（同时向后移植到了Java 8u191）：

-XX:MinRAMPercentage
-XX:MaxRAMPercentage
-XX:InitialRAMPercentage

本文不会详细介绍这些参数如何工作，但是关键点是这些参数可以在不需要直接设置堆内存大小的情况下用于调优JVM堆大小。也就是说，容器仍然可以依赖对其设置的资源限制。

那么，这些参数的值该怎么设置呢？答案是：看情况，尤其是依赖于容器上设置的资源限制。

默认设置下，JVM堆内存会设置成容器内存的25%。我们可以通过这些参数来修改初始、最小、最大堆内存。例如，设置-XX:MaxRAMPercentage=50将会允许JVM将容器内存的50%作为堆内存使用，而不是默认的25%。这样设置是否安全主要取决于容器运行的内存以及容器内的进程情况。

例如，假设容器只运行一个Java进程，分配了4GB内存，而我们设置了-XX:MaxRAMPercentage=50，此时JVM堆内存上限是2GB。这与默认情况下只能使用1GB内存不同。在这种情况下，50%基本上是非常安全的，也许也是最佳的，因为还有许多可用内存实际利用率都不高。相反，假设相同的容器只分配了512MB内存，现在设置了-XX:MaxRAMPercentage=50之后，堆内存会占用256MB内存，而对于容器剩下的所有可用内存就只有256MB了。这些内存需要被容器中运行的其他进程共享，同时还有JVM的Metaspace/PermGen等其他内存使用。因此在这种场景下，50%可能不太安全。

这里提供如下建议：

除非想为Java进程压榨额外内存，否则不要修改这些参数。在大部分情况下默认值25%对于内存管理来说是比较安全的。这个设置对内存来说可能并不是最有效的，但是内存是相对廉价的，同时相比于JVM进程在未知情况下被OOM-kill，还是谨慎一些比较好。
如果非要调试这些参数，还是保守点为妙。50%通常是个安全值，可以避免（大部分）问题。当然，这还是主要取决于容器内存大小。我不推荐设置成75%，除非容器至少有512MB内存（最好是1GB），同时需要对应用程序的实际内存使用非常了解。
如果容器内除了Java进程之外还有其他进程，那么在调整这些值的时候需要额外的注意。容器内存由其中所有进程共享，因此在这种情况下，了解整个容器内存使用会更加复杂。
设置成超过90%可能是在自找麻烦。

对于Metaspace/PermGen/其他内存呢？

这已经超出了本文的范围，不过这些也可以调整，通常情况下最好不要。大多数情况下，JVM默认行为已经很好了。如果你发现自己正试图解决一个晦涩的内存问题，那么可能需要研究一下JVM内存这个深奥的领域。其他情况，我尽可能避免直接去修改。

对于CPU

对于CPU没有什么可做的。从Java 8u191开始，JVM默认情况下已经实现“感知容器”，能够正确解析CPU共享（CPU Share）设置。这里有一些细节需要理解，因此我直接附上一篇不错的文章，详细介绍相关知识，就不在本文中概述。

总结

现代的Java已经为容器环境做好了准备，但是为了应用程序能够有更好的性能，其中有一些不是那么明显的细节需要我们了解。我希望本文提供的信息，加上优秀的参考文献，可以帮助读者达到这个目的。

参考文献

附录：

在64GB/16GB JVM例子中，这里并不是说JVM进程会为堆内存自动消费16GB内存，只是说在内存溢出之前，堆内存可以增长到那么大。另外，由于设置的最大堆内存还有很多，对于垃圾回收器来说没有压力，堆内存很容易在触发垃圾回收之前，消耗多余容器实际可以提供的内存。这必然会引起应用程序问题（例如OOM错误），甚至更严重的错误（例如被OOM kill，崩溃）。

原文链接：

https://www.ccampo.me/java/docker/containers/kubernetes/2019/10/31/java-in-a-container.html

创作场景

在容器中使用 Java 的资源分配准则