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

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

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

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

# custom IntelliJ IDEA VM options


-Xms2048m
-Xmx2048m

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

Xms和Xmx参数定义

在启动 Java 应用程序时,我们通常可以通过参数XmsXmx来配置 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一般都是设置相等的。

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

其实关于在生产环境中把XmsXmx设为相同值也是 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虚拟机,XmsXmx设置为一样的,可以减轻伸缩堆大小带来的压力。但对于IBM虚拟机,设置为一样会增大堆碎片产生的几率,并且这种负面影响足以抵消前者产生的益处。

小结

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

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

1 人点赞