不提供 Xms JVM 参数有什么缺点？

Question

我正在寻找一种策略来调整我正在运行的应用程序的 JVM 参数。

该应用程序本身是一个 web 应用程序，大部分时间不会做太多，也不需要太多 memory。 假设 300MB。 时不时地有一些外部触发大量繁重的处理，偶尔需要更多的 memory。 假设 1400 MB。

我在 JDK 15 上运行，在 kubernetes 集群中的 pod 上没有任何其他 JVM 参数。

我想要：

• 确保我的应用程序继续运行
• 确保我的应用程序从底层系统中占用的 memory 不会比保持其运行实际需要的多。

在四处寻找答案时，经常弹出的建议是设置Xmx参数。 我明白为什么，这对我来说很有意义。

但是还有另一个让我困惑的常见建议。 也就是设置Xms参数，设置为equal to the Xmx参数。

在过去的几周里，我设置了这两个参数并同样配置了它们，都是 1400M。

• 顶部的蓝线是在底层系统（堆+其他）上总共保留了多少 memory
• 它下面的黄色直线是 memory 和 JVM 实际为堆保留/提交的数量。
• 底部的紫色线是 memory 目前实际使用了多少堆。

我得出的结论是，一切运行顺利，看起来可以预测。 我不喜欢的是 JVM 始终保留 1400MB memory （这正是我假设的 Xms 参数），永久占用 2.2 GB 的底层系统。

让我们看看当我删除 Xms 参数并将 Xmx 设置为 1400 时会发生什么：

在这里，您可以更清楚地看到应用程序的典型行为。 memory 和 JVM 为堆保留/提交多少取决于实际使用了多少。 它大部分时间都很低，在繁重的处理过程中会上升和下降。

我的问题是：为什么要设置 Xms 参数？ 没有它的行为看起来效率更高。 我有什么缺点吗？

Answer 1

如果其他一些应用程序保留太多 memory，那么您的应用程序在下一个高峰期将不够用。

如果保留大小没有变化，管理员可以更好地估计 memory 的使用情况。

一次保留的 memory 很可能碎片较少。

但是设置圣诞节有一个缺点（除了明显的那个）：垃圾收集器在开始收集之前等待更长的时间。 垃圾收集开销很少，但更重。 在这种情况下，CPU 性能不太稳定。 在某些情况下，它可能会导致停顿（例如，如果您有大量 RAM 但 CPU 较弱）