短短几年，容器就改变了软件行业的开发模式。也许，很多开发者已经开始在容器中运行 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 已经为容器环境做好了准备，但是为了应用程序能够有更好的性能，其中有一些不是那么明显的细节需要我们了解。我希望本文提供的信息，加上优秀的参考文献，可以帮助读者达到这个目的。
参考文献
- Nobody Puts Java In A Container
- JVM Memory Settings in a Container Environment
- JDK 8u181 release notes regarding container support
- Docker support in Java 8 — finally!
- How to correctly size containers for Java 10 applications
- Docker and the JVM
- Java 8: From PermGen to Metaspace
- Analyzing Java memory usage in a Docker container
- Kubernetes throwing OOM for pods running a JVM
- CPU considerations for Java applications running in Docker and Kubernetes
- Kubernetes: Managing Compute Resources for Containers
- Docker: Runtime options with Memory, CPUs, and GPUs
附录：
在 64GB/16GB JVM 例子中，这里并不是说 JVM 进程会为堆内存自动消费 16GB 内存，只是说在内存溢出之前，堆内存可以增长到那么大。另外，由于设置的最大堆内存还有很多，对于垃圾回收器来说没有压力，堆内存很容易在触发垃圾回收之前，消耗多余容器实际可以提供的内存。这必然会引起应用程序问题（例如 OOM 错误），甚至更严重的错误（例如被 OOM kill，崩溃）。
原文链接：
https://www.ccampo.me/java/docker/containers/kubernetes/2019/10/31/java-in-a-container.html
评论