JVM内存变化分析实战

news2024/11/24 23:01:10

最近在一次项目压力测试时，监测到JVM内存明显的变化，由于之前开发工作中没有涉及到JVM相关的问题分析，所以特此借这个机会学习和记录。项目使用的JDK版本为 OpenJdk 1.8，虚拟机为 HotSpot。

1. 内存变化情况

在压力测试进行2H48Min时，JVM内存出现明显变化，内存最大占用量为1.53G，最大波动量在800MB左右，具体图示如下

2. 内存变化情况

2.1 元空间变化情况

元空间.png

在JDK1.8中，方法区是使用 元空间 来实现的。元空间使用的是 本地内存 ，其中存储有 类型信息 、常量、 静态变量 和 即时编译器编译后的代码缓存 等数据。 运行时常量池 也是方法区的一部分，它存放的是Class文件中在编译期生成的常量池表和运行期间新生成的常量。从上图中可以发现，该内存区域使用内存大小没有发生改变，所以方法区与本次JVM内存变化情况无关。

2.2 年轻代内存变化情况

年轻代内存变化.png

年轻代伊甸园区占用内存从544MB减少到94MB，变化了450MB；年轻代Survivor区从0MB增加到129MB并又随后减少到0MB。

2.3 老年代内存变化情况

老年代.png

老年代内存从104MB增加到1.12GB，之后经历老年代GC又减少到831MB，变化量约为727MB，与堆内存总变化量接近。

3. 内存变化分析

3.1 年轻代GC分析

PS Scavenge 表示新生代使用的是 Parallel Scavenge 垃圾收集器，它采用的是 标记-复制 算法。标记-复制算法在对年轻代进行收集时，采用复制分代策略，将年轻代划分为伊甸园区和两个Survivor区，比例为8:1:1，本次项目JVM分配的堆内存大小为2G，那么内存大小比例为1638.4M:204.8M:204.8M，算法执行时会直接将Eden和其中一个Survicor区中存活的对象复制到另一个Survivor区，如果Survivor区不足以保存存活的对象，那么会触发 逃生门 机制直接将对象移至老年代。

从年轻代内存变化图示中可以发现，对年轻代进行垃圾回收时，Survivor区从0M变化到129M。0M说明之前Survivor区并没有被使用，如果因此推测每次GC没有对象存活的话，那么显然是不准确的，因为没有对象存活那么怎么才能导致老年代内存变化，难道是因为一次性创建了800M的大对象直接分配到了老年代（不可能）？

如果考虑标记复制算法因存在 逃生门 机制，导致Survivor区长时间是0M，那么应该在能够在Survivor区0M使用的时间里观察到老年代有明显的内存升高才对（对象大小超过204.8M直接分配到老年代），但是在老年代内存变化图示中没有相关变化。

在这里已经陷入了困惑，猜测可能是因为监控数据每15s采集一次而每次GC的平均时间在500ms，导致没有监控到Survicor区的内存变化而产生的这种情况。可能实际上Survicor区有被使用，即每次GC后有对象存活，否则老年代内存的升高从何而来？而且我们能够发现老年代内存变化除较大波动的范围外，其他时间是一条斜率较小的线，也证明着有小对象随着垃圾回收不断的往老年代中加入，不过本次内存的较大波动无从分析。

而且图示中Survivor区增加到129M，这个数据很可能是不够准确的。在图示中可以发现申请的（Committed）内存大小最大有223M之多，与监控到的最大使用内存129M相差近100M，理论上申请内存大小与使用内存应该比较接近才对，所以在这里也能发现监控数据的异常。

3.2 老年代GC分析

从图示中可以发现老年代GC是 PS Mark Sweep ，表示 标记-清除 算法，以此推断老年代使用的是 CMS 收集器。它是一种以获取最短停顿时间为目的收集器，会经历初始标记、并发标记、重新标记和并发清除四个阶段，图示中GC耗时在2s左右。CMS在启动时会默认要求分配 （核心处理数 + 3） / 4 个核数，本次压测服务器核数为32，那么在执行回收时会分配8核左右，GC完成后老年代内存从1.12GB减少到831M。

3.3 总结

基于不准确的数据判断和推测：JVM堆内存变化是年轻代中的对象在进行垃圾回收时被转移到老年代导致的，但是没有准确的数据支撑这个结论看起来非常牵强，而且还有一点需要注意：项目服务端使用Netty搭建，调用本地方法在本地内存中生成的对象虽然不直接占用堆内存，但是它也会有在Java堆里的 DirectByteBuffer 对象作为这块内存的引用，不清楚这会不会造成堆内存的升高。

由于本次压测的关注重点并不在此，而在于内存和CPU的最大使用情况，所以之后并没有调整数据采集时间间隔再进行压测，如果之后再进行压力测试应注意该参数的设置。