容器中Java RAM的使用：不会丢失内存的5大技巧

在本文中，我们希望分享Java内存管理的细节和容器内部的弹性，这些细节乍一看并不明显。

在下面，您将找到要注意的问题列表以及即将发布的JDK版本中的重要更新，以及针对核心痛点的现有解决方法。我们收集了5个最有趣，最有用的技巧，以提高Java应用程序的资源使用效率。

Docker中的Java堆内存限制

当前，社区正在讨论有关在Docker容器中运行Java应用程序时错误地确定内存限制的问题。

问题是，如果未明确定义Xmx选项，则由于默认的内部垃圾回收（GC）人机工程学算法，JVM使用了可用于主机OS的所有内存的1/4。如果JVM内存使用量超过为Docker容器定义的cgroups限制，则可能导致内核杀死Java进程。

为了解决此问题，OpenJDK 9最近实现了一项改进：

OpenJDK 9已添加了第一个实验性更改，因此JVM可以了解它正在容器中运行并相应地调整内存限制。” 如果使用Docker运行Java 9发行版将调整内存限制

新的JVM选项（ -XX：+ UseCGroupMemoryLimitForHeap ）根据cgroup中定义的内存限制自动为Java进程设置Xmx。

作为解决公共Java 9发行前问题的一个不错的解决方法，可以在JVM的启动选项中显式指定Xmx限制。 OpenJDK官方仓库中有一个公开拉取请求，要求“根据docker内存限制设置一个更好的默认Xmx值的脚本”。

Jelastic设法通过结合使用增强的系统容器虚拟化层和Docker映像来省略错误的内存限制确定。在前面的文章“容器中的Java和内存限制：LXC，Docker和OpenVZ”中，我们解释了它的工作原理。

跟踪本机非堆内存使用情况

在云中运行Java应用程序时，还必须注意Java进程对本机内存的使用，即所谓的堆外内存。它可以用于不同目的：

垃圾收集器和JIT优化正在跟踪对象图的数据并将其存储在本机内存中。此外，自JDK8起，类的名称和字段，方法的字节码，常量池等现在位于Metaspace中，该空间也存储在JVM堆之外。

另外，为了获得高性能，许多Java应用程序在本机区域分配内存。使用java.nio.ByteBuffer或第三方JNI库，这些应用程序存储大型的，长寿命的缓冲区，这些缓冲区由基础系统的本机I / O操作管理。

默认情况下，元空间分配仅受可用本机OS内存量的限制。再加上Docker容器中错误的内存限制确定，这增加了应用程序不稳定的风险。限制元数据的大小很重要，尤其是在遇到OOM问题时。使用特殊选项-XX：MetaspaceSize来执行此操作。

由于所有对象都存储在正常的垃圾回收堆内存之外，因此，它们对Java应用程序的内存占用量有什么影响并不明显。有一篇很好的文章详细解释了该问题，并提供了一些有关如何分析本机内存使用情况的准则：

“几周前，我在尝试分析在Docker下运行的Java应用程序（Spring Boot + Infinispan）中的内存消耗时遇到了一个有趣的问题。 Xmx参数设置为256m，但是Docker监视工具显示的已用内存几乎增加了两倍。” – 分析Docker容器中的Java内存使用情况。

作者的有趣结论：

“我可以说一个结论吗？ 好吧……永远不要在我开玩笑的同一句话中使用“ java”和“ micro”这两个词–请记住，在使用Java，Linux和Docker的情况下处理内存比起初看起来要棘手得多。”

为了跟踪本机内存分配，可以使用特定的JVM选项（ -XX：NativeMemoryTracking = summary ）。请注意，如果启用此选项，您将获得5-10％的效果。

在运行时调整JVM内存使用量

减少Java应用程序内存消耗的另一个有用的解决方案是在Java进程运行时动态调整JVM可管理选项。由于JDK7u60和JDK8u20，选项MinHeapFreeRatio和MaxHeapFreeRatio成为可管理的，这意味着我们可以改变在运行时它们的值，而无需重新启动Java进程。

在“ 运行时承诺的堆大小调整”一文中，作者描述了如何通过调整以下可管理选项来减少内存使用：

“…调整大小又花了一个时间，并且堆容量从159MB增加到444MB。 我们描述了至少85％的堆容量应该是可用的，并且这表明JVM调整了堆的大小以获取最多15％的使用率。”

这种方法可以为可变工作负载带来显着的资源使用优化。改善JVM内存大小的下一步是可以在运行时模式下更改Xmx，而无需重新启动Java进程。

改善内存压缩

在许多情况下，客户希望最大程度地减少Java应用程序中使用的内存量，从而导致产生更频繁的GC。例如，它可以通过在开发，测试和构建环境以及负载高峰后的生产中更有效地利用资源来帮助节省资金。但是，根据官方的增强票证，当前的GC算法需要多个完整的垃圾回收周期才能释放所有可用的未使用内存。

结果，引入了新的JVM选项（ -XX：+ ShrinkHeapInSteps ）来调节JDK9中的GC算法行为。该设置应更改为-XX：-ShrinkHeapInSteps，以禁用4个完整的GC周期。这样可以更快地释放未使用的RAM资源，并最大程度地减少负载可变的应用程序中Java堆大小的使用。

减少内存使用以加快实时迁移

占用大量内存的Java应用程序的实时迁移需要大量时间。为了减少总迁移时间和资源开销，迁移引擎应尽量减少主机之间传输的数据。这可以通过在实时迁移过程之前借助整个GC周期压缩RAM来完成。对于克服GC周期期间性能下降的情况，这种方法对于各种应用程序而言，与使用未打包的RAM进行迁移相比可能更具成本效益。

我们发现了与该主题相关的出色研究工作： GC辅助Java Server Applications的JVM Live Migration 。作者将JVM与CRIU（在用户空间中的Checkpoint / Restore）集成在一起，并引入了一种新的GC逻辑，以减少Java应用程序从一台主机实时迁移到另一台主机的时间。提供的方法允许在获取Java进程状态的快照之前启用可感知迁移的垃圾收集，然后通过在磁盘上检查点来冻结正在运行的容器，然后从冻结点恢复容器。

另外，Docker社区正在将CRIU集成到主流中。目前，此功能仍处于试验阶段。

Java和CRIU的组合可以释放仍未发现的性能和部署优化机会，以改善云中Java应用程序的托管。您可以在“ 容器实时迁移：幕后 ”一文中找到有关容器实时迁移如何在云中工作的更多详细信息。

Java很棒，并且已经在云中（特别是在容器中）很好地工作了，但是我们相信它会更好。因此，在本文中，我们介绍了一系列当前问题，可以对这些问题进行改进，以平稳高效地运行Java应用程序。

在Jelastic，我们在全球数百个数据中心中运行着数千个Java容器。良好的内存管理对我们至关重要。这就是为什么我们不断将有关Java内存的新发现纳入我们的平台的原因，因此开发人员不必明确处理这些问题。尝试在Jelastic增强平台上运行Java容器。