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

Question

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

该应用程序本身是一个网络应用程序，大多数时候不做太多事情，也不需要太多内存。假设300MB。时不时地，外部的一些东西会触发大量的繁重处理，偶尔需要更多内存。假设1400 MB。

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

我想：

• 确保我的应用程序持续运行
• 确保我的应用程序从底层系统占用的内存不会比保持其运行所需的内存多得多

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

但是还有一个常见的建议让我感到困惑。它也设置Xms参数，并将其设置为等于Xmx参数。

在过去的几周里，我设置了这两个参数，并将它们平均配置为1400M。

• 顶部的蓝线是底层系统上总共保留了多少内存（其他堆）
• 它下面的黄色直线是JVM实际为堆保留/提交的内存量
• 底部的紫色线表示当前实际使用的堆内存量

我得出的结论是，一切运行顺利，看起来可以预测。我不喜欢的是JVM在任何时候都保留1400MB内存（这正是我假设的Xms参数），永久占用基础系统的2.2GB。

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

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

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

Answer 1

如果其他应用程序保留了太多内存，那么在下一个峰值期间，您的应用程序将没有足够的内存。

如果保留大小不变，管理员可以更好地估计内存使用情况。

立即保留的内存很可能不会那么零碎。

但是设置Xms参数有一个缺点（除了明显的缺点）：垃圾回收器在开始收集之前等待的时间更长。垃圾回收机制开销更少，但更重。在这种情况下，CPU性能不太稳定。在某些情况下，它会导致世界停止暂停（例如，如果您有大量RAM但CPU较弱）