JVM的Xms和Xmx参数设置为什么要设置为相同值

2020-09-08 10:27:39 浏览数 (3)

文章转载自公众号：程序新视界

最近正在重新学习 JVM 的内存结构及相关优化内容，无意中看到 IDEA 的 VM 配置（安装时默认配置）中有如下的配置：

# custom IntelliJ IDEA VM options


-Xms2048m
-Xmx2048m

看到 Xms 和 Xmx 的参数设置一样，是不是稍微有些奇怪？这里就写篇文章分析一下，JVM 的 Xms 和 Xmx 参数设置为相同的值有什么好处？首先来了解一下相关参数的概念及功能。

Xms和Xmx参数定义

在启动 Java 应用程序时，我们通常可以通过参数Xms和Xmx来配置 JVM 的堆信息。不配置虽然会有默认值，但如果受硬件所限或需对 JVM 进行调优，则需要根据情况指定这两个参数的值。

-Xms：堆内存的最小Heap值，默认为物理内存的1/64，但小于1G。默认当空余堆内存大于指定阈值时，JVM 会减小heap的大小到-Xms指定的大小。

-Xmx：堆内存的最大Heap值，默认为物理内存的1/4。默认当空余堆内存小于指定阈值时，JVM 会增大Heap到-Xmx指定的大小。

内存情况的变化

常规的JVM参数使用如下：

java -Xms512m -Xmx1g

在这种配置下，JVM 启动时会分配512M的堆内存空间，随着程序的执行，所需的堆空间越来越大，则会逐渐增大堆内存空间，直到Xmx参数指定的堆最大空间1G。

当堆内存使用率降低，则会逐渐减小该内存区域的大小。整个过程看似非常合理，但为什么很多生产环境却也将两个值配置为相同的值呢？

JVM垃圾回收的不足

当堆内存使用情况变化时，并不是单纯的扩大和缩小堆内存就完事了。在此之前还会执行GC（垃圾回收）操作。如果-Xms起初值设置的比较小，那么就频繁触发GC操作。当GC操作无法释放更多内存时，才会进行内存的扩充。

我们都知道GC操作是需要耗时的，而且Full GC会引起“Stop the World”，也就是说会引起线程停止，不可避免就会引起性能问题。

相同值的好处

面对上面的问题，为了避免在生产环境由于heap内存扩大或缩小导致应用停顿，降低延迟，同时避免每次垃圾回收完成后JVM 重新分配内存。所以，-Xmx和-Xms一般都是设置相等的。

当然，如果生产系统上线前有一段预热时间的话，也可以不设置相等。对于需要高吞吐量的应用来说，可以不在乎这种停顿，比如一些后台的应用之类，那么内存可以适当调大一些。(停顿时间越长，吞吐量反而越大)，需要根据具体情况权衡。

其实关于在生产环境中把Xms和Xmx设为相同值也是 Oracle 官方推荐的。在Xms的参数描述中有这样一段话：

Oracle recommends setting the minimum heap size (-Xms)equal to the maximum heap size (-Xmx) to minimize garbage collections.

其实这里还有一个小前提，那就是生产环境往往一台服务器或一个容器只有一个服务，独占服务器意味着没有必要调整 JVM 大小，每次调整反而会加大开销。只有在多开发环境，比如个人电脑等运行进程比较多时，动态调整JVM才有必要。

注意事项

其实虽然设置为相同值有很多好处，但也会有一些不足。比如，如果两个值一样，会减少 GC 的操作，也意味着只有当 JVM 即将使用完时才会进行回收，此前内存会不停的增长。

并且同一 JDK 的 GC 策略也有很多种，不能一概而论。另外，对于Hotspot虚拟机，Xms和Xmx设置为一样的，可以减轻伸缩堆大小带来的压力。但对于IBM虚拟机，设置为一样会增大堆碎片产生的几率，并且这种负面影响足以抵消前者产生的益处。

小结

最近研究 Java 虚拟机比较多一些，越研究发现越有意思，越研究发现很多之前没弄明白的问题都慢慢融会贯通了。强烈建议大家有时间的话读读相关的书籍，研究一些用法的底层逻辑。

以上就是W3Cschool字节宝关于JVM的Xms和Xmx参数设置为什么要设置为相同值的相关介绍了，希望对大家有所帮助。

Java

0 人点赞