使用maven时，如何修改JVM的配置参数；maven命令执行时到底消耗多少内存？

Posted 2020-10-21 沧海一粟，何以久远

maven是使用java启动的，因此依赖JVM，那么如何修改JVM参数？

 

 

MAVEN_OPTS

在系统的环境变量中，设置MAVEN_OPTS，用以存放JVM的参数，具体设置的步骤，参数示例如下：

　　MAVEN_OPTS=-Xms256m -Xmx768m -XX:PermSize=128m -XX:MaxPermSize=256M  

　　或者临时设置 export MAVEN_OPTS=-Xms256m -Xmx768m -XX:PermSize=128m -XX:MaxPermSize=256M

在mvn中添加MAVEN_OPTS

      找到Maven的安装目录，在bin目录下，编辑mvn.bat(linux下，mvn)

　　set MAVEN_OPTS=-Xms256m -Xmx768m -XX:PermSize=128m -XX:MaxPermSize=256M  

Vim mvn：

 

设置JVM最大堆heap内存为一个很小的值5m，如图，报错：GC overhead limit exceeded

 查看详细信息：OOM了

 关于下图标识的含义: 27M表示构建结束的时刻所使用的堆heap大小；535M表示构建结束时刻的分配的堆大小

分配的堆大小需要 > 使用的堆大小，不然就会内存溢出OOM

 

Here :

Final Memory: 47M/535M

47M is the used memory and 535M the current allocated memory (heap size) by the JVM at the end of the build.
But these information could not give you the peak value.

Why the used memory (43M) cannot be considered as the peak ?

• Because the peak may have occurred before the end of the build.

Why the heap size (636M) cannot be considered as the peak ?

• Because the peak may be superior to the heap size if the GC reduced the heap size between the peak and the end of the build .
  It may be the case for a very long build that performs intensive tasks at the beginning and lighter tasks then.

• Because the peak may be inferior to the heap size if the GC has increased the heap size until this value but the application never needs to consume as much as memory.

To get the memory peak during the execution of the maven build, monitor the Java application (maven execution) with any JVM tool designed for : JVisualVM or JConsole for example. 

Here\'s an screenshot of a maven build of a Spring Boot application monitored by JVisualVM that shows that neither the heap size or the used size at the end of build are the peak value :

JVisualVM is the best as it can be used to monitor several processes at once. And when running the maven build, make sure to open(double click) the relevant processes generated under the Applicationwindow of the JVisualVM as the build processes are killed once after the built is completed making you unable to monitor the process. By opening the relevant process before it is being killed, will allow to monitor the build process well.

 

Yes, and if you have e.g. unit tests, the surefire plugin starts parallel an additional process without using MAVEN_OPTS for that.

maven的单元测试插件会另外起个进程，这个进程的堆大小不受MAVEN_OPTS的配置约束，所有说maven命令行执行，内存到底够不够，关键看两个参数，一个是主进程的堆heap的峰值peak；一个是单测插件surefire起的进程的所需堆heap的峰值peak。因为一个项目有多个模块moduls，那就得看最消耗heap的那个模块的峰值peak

 

如下图所示，会在某个时刻出现一个所需堆heap的极值，如果系统不能满足这个大小，就会OOM（out of memory）内存溢出

 

另外surefire插件到底可以jvm再拉出几个进程，以及每个进程的jvm配置是如何的，都是可以配置的，参考：http://maven.apache.org/surefire/maven-surefire-plugin/examples/fork-options-and-parallel-execution.html

还有就是surefire可以不另起进程，这样减少内存的使用，见插件官网说明

至于配置几个并行进程，就要看设备内存已经项目执行时间要求。要么时间换空间，要么空间换时间。Choosing the right forking strategy and parallel execution settings can have substantial impact on the memory requirements and the execution time of your build system.

 

 

export MAVEN_OPTS=-Xmx512m这个参数的左右是，可以减少GC的压力

How do I interpret the "Final Memory" reported by Maven? "66M/188M" for
example, what does each of the figures mean?

In general the JVM only looks for more memory (up to -Xmx) when it needs
it, so consider that to be the peak requirement (not peak usage as the JVM
will always ask for more than usage on the basis that it needs room to
allocate objects)

If you run Maven with -Xmx2048m you will remove the pressing need for GC,
but the total memory might still only be 188MB as that may just have been
the largest amount of that 2048MB that the JVM needed at some point in time
during the build

参考：

1、http://grokbase.com/t/maven/dev/12bvc2s2bt/final-memory-reported-by-maven

2、https://stackoverflow.com/questions/45418317/how-to-find-the-peak-memory-usage-in-a-maven-build?answertab=votes#tab-top

3、http://maven.apache.org/surefire/maven-surefire-plugin/