解决JVM堆内存不断扩容导致服务器内存耗尽的问题

文章目录

• 应用场景：
• 问题描述：
• 原因分析：
• 解决方案：
• 软件版本

应用场景：

采用Spring Boot搭建Web应用，打成jar包，通过内置Tomcat运行。每台服务器上面部署了十几个应用，都是通过java -jar xxx.jar启动，整个系统可以正常运行。

问题描述：

在系统运行一段时间后，发现服务器内存被占满。

[root@i ~]# free -h
               total       used         free       shared     buff/cache   available
Mem:           125G        112G         3.0G        439M         10G           11G
Swap:          14G         6.2G         8.4G

从上面的内存信息中，可以看出可用的内存空间已经不足。然后通过top命令查看进程占用内存的情况

使进程按内存占用大小倒序排列，图中显示占用内存多的都是java程序。
看到这些信息，初步判定是发生内存泄漏了，对象无法回收，导致堆内存老年代不断增加。接下去我们选择一个占用内存最大的进程来分析，验证当前的判断。

原因分析：

通过jps -l可以列出JVM进程号和应用名称，如下图所示

对比进程号就可以看出哪个程序占用内存多。然后使用jstat命令查看Java进程中JVM内存的使用情况

[root@i ~]# jstat -gcutil 2113 1000 1
  S0     S1     E      O      M     CCS    YGC     YGCT    FGC    FGCT     GCT   
  0.00  99.85  12.80  30.18  93.81  90.63   1975  125.783     5    1.049  126.832

这里显示的是JVM各个内存区域的使用占比。除了占比我们还可以看一下实际占用内存的大小

[root@i ~]# jstat -gc 2113 1000 1
 S0C    S1C    S0U    S1U      EC       EU        OC         OU       MC     MU    CCSC   CCSU   YGC     YGCT    FGC    FGCT     GCT   
191488.0 52736.0  0.0   52656.0 10113024.0 1490370.4 2833920.0   855148.1  118292.0 110974.1 13884.0 12582.7   1975  125.783   5      1.049  126.832

这里显示了各个内存区域的大小和已使用的大小，单位是KB。当然这种方式可读性比较差，不直观，为了方便的查看JVM运行信息呢，
我选择使用VisualVM通过远程连接查看服务器上面Java进程。

这里显示了服务器上面2113这个进程的JVM内存信息，可以看出堆内存大小为12.7G，实际使用为2.9G，实际占用并不多。
接下来我们通过Visual GC插件来看一下堆内存年轻代和老年代的分布情况

从这张图上面，我们可以直观的看出实际内存使用并不多，大量的内存处于空闲状态，到这里我们可以确定程序并没有出现内存泄漏，对象可以被正常回收。
但是大量的内存空闲，占用了系统的本地内存，影响了其他程序的运行。其中Eden区最大，占了9.6G，最大值是9.9G。这个最大值9.9G是一个默认值，
如果启动Java程序的时候设置JVM参数，则使用默认值。我们可以使用jinfo命令看一下Java进程启动时设置的参数

[root@i bin]# jinfo -flags 2113
Attaching to process ID 2113, please wait...
Debugger attached successfully.
Server compiler detected.
JVM version is 25.181-b13
Non-default VM flags: -XX:CICompilerCount=15 -XX:InitialHeapSize=2111832064 -XX:MaxHeapSize=32210157568 -XX:MaxNewSize=10736369664 -XX:MinHeapDeltaBytes=524288 -XX:NewSize=703594496 -XX:OldSize=1408237568 -XX:+UseCompressedClassPointers -XX:+UseCompressedOops -XX:+UseFastUnorderedTimeStamps -XX:+UseParallelGC

从上面的信息中可以得出最大堆内存MaxHeapSize=32210157568（29.9G），最大新生代内存MaxNewSize=10736369664（9.9G），
MinHeapDeltaBytes=524288这是堆内存最小扩容值512KB，当Eden区域不够时，JVM会尝试扩容来避免频繁的垃圾回收。
对于并发量高的程序，在短时间内创建大量新对象，Eden区域不足，触发扩容，直到最大值，在垃圾回收之后又空出大量的内存。
因为每个程序的并发量不一样，所以扩容的速度也不一样。没有设置JVM参数是导致JVM内存不断扩容，占用大量内存的最大原因。

解决方案：

根据以上分析结果，针对JVM内存的实际使用情况，在程序运行时设置JVM参数

java -server -Xms3g -Xmx3g -Xmn2g -XX:SurvivorRatio=8 
-XX:-UseAdaptiveSizePolicy -XX:MetaspaceSize=128m -XX:MaxMetaspaceSize=256m -XX:+UseParallelGC -XX:+UseParallelOldGC -jar xxx.jar

采用server模式可以优化预编译处理，提高程序后续的执行速度。
堆内存大小设置为3G，可以根据程序的实际负载调整堆内存大小，一般程序3个G够用了。
年轻代大小设置为2G，Survivor区和Eden区比值设置为1:1:8，增加年轻代大小可以避免频繁垃圾回收，导致对象提前进入老年代。
因为并发垃圾回收器默认使用了-XX:+UseAdaptiveSizePolicy，所以即使设置了SurvivorRatio，Survivor区和Eden区的大小还是自适应的，这会导致Survivor区很小，在垃圾回收时如果Survivor区装不下，对象会直接进入老年代，所以我们使用-XX:-UseAdaptiveSizePolicy关闭内存大小自适应。
元空间触发垃圾回收的值设置为128M，MetaspaceSize不是元空间的初始大小，而首次触发垃圾回收的阈值，设置一个足够大的值可以避免程序加载过程中触发垃圾回收，降低程序运行效率。
年轻代和老年代都使用并发垃圾回收器，减少垃圾回收时程序的等待时间。
通过对JVM参数的优化，即避免Java进程过多的占用内存，又可以提高程序的运行效率。

软件版本

JDK：1.8
Spring Boot：2.1.9.RELEASE