jvm疯狂吞占内存，罪魁祸首是谁

超、凢脫俗 2022-04-17 03:08 220阅读 0赞

分享一篇公司小伙伴的关于jvm占用内存的技术文章

**导读：JVM是Java Virtual Machine的缩写，中文名为Java虚拟机。它是一种用于计算设备的规范，是一个虚构出来的计算机，主要通过在实际的计算机上仿真模拟各种计算机功能来实现的。在实际运用过程中，易观技术人员注意到一台开发机上各个微服务进程占用内存很高，随即便展开了调查......**

**现象：**前段时间发现某台开发机上各个微服务进程占用内存很高，这里记录下解决思路，仅供参考。

Centos6.10+Jdk1.8+SpringBoot1.4.4环境下各个JVM进程所占内存使用情况

![1541750902773-1.png][]

VIRT和RES都很高......

以其中某个进程为例（进程启动日期为8月9日，排查时候的时间是8月10日10:54:58，也就是说该进程运行时间应该不会超过48小时）

![1541750921931-2.png][]

top命令查看该进程占用内存情况（可以看到此进程已经占用2.7G物理内存）

![1541750931906-3.png][]

为了排除掉是因为中途有压力测试的嫌疑，将此服务进行了重启，但是刚起的进程(19146)，

占内存情况RES:1.8G,  VIRT:33.4G  …

![1541750946493-4.png][]

JVM进程动不动就是2G以上的内存，然而开发环境并没什么业务请求，谁是罪魁祸首 ？

解决问题之前，先复习下几个基础知识。

**1. ****什么是RES和VIRT？**

RES：resident memory usage 常驻内存

**（1）进程当前使用的内存大小，但不包括swap out**

**（2）包含其他进程的共享**

**（3）如果申请100m的内存，实际使用10m，它只增长10m，与VIRT相反**

**（4）关于库占用内存的情况，它只统计加载的库文件所占内存大小 **

RES = CODE + DATA

VIRT：virtual memory usage

**（1）进程“需要的”虚拟内存大小，包括进程使用的库、代码、数据等**

**（2）假如进程申请100m的内存，但实际只使用了10m，那么它会增长100m，而不是实际的使用量**

VIRT = SWAP + RES

**2. Linux****与进程内存模型** ![1541751012806-6.png][]

**3. JVM****内存模型（1.7与1.8之间的区别）**

![1541751004593-7.png][]

所以JVM进程内存大小大致为：

非heap（非heap=元空间+栈内存+…）+heap+JVM进程运行所需内存+其他数据

那么会是jvm内存泄漏引起的吗？

使用Jmap命令将整个heap dump下来，然后用jvisualvm分析

可以看到，堆内存一切正常（dump会引起FGC,但并不影响此结论）

那么可能是java进程本身的原因吗？

为了验证此问题，通过部署系统在开发机上起了1个没有任何业务代码的java进程，仅仅是引入注册中心

![1541751093337-8.png][]

查看此进程内存占用情况：

![1541751102420-9.png][]

明显已经设置了Xmx为512MB，虽然Xmx不等于最终JVM所占总内存，但至少也不会偏差太多； 那么使用jmap命令查看当前jvm堆内存配置和使用情况（下面的图2是在图1现场5分钟之后截取的）

![1541751112527-10.png][]

（图1）

![1541751139421-11.png][]

（图2）

所以从2次的jmap结果中，可以得出以下几个结论：

我们的Xmx设置并没有生效，因为MaxHeapSize≠Xmx

图1中jvm占用内存计算：

元空间(20.79MB)+ eden(834MB)+年老代(21MB)+线程栈（38\*1024KB）+JVM进程本身运行内存+ NIO的DirectBuffer +JIT+JNI+…≈top(Res) 1.1G

当前jvm线程数统计：jstack 7311 |grep ‘tid’|wc –l  (linux 64位系统中jvm线程默认栈大小为1MB)

Eden区进行了多次扩容，由图1可知eden区可用空间已经不够用了（容量：843MB，已使用：834MB），图2中扩容到1566MB

Eden区经历了Minor Gc，由图2可知eden区已使用空间：60MB，说明之前在eden区的对象大部分已经被回收，部分未被回收的对象已经转入到扩展1区了

**Xmx****设置为何未生效？**

查看部署系统的启动脚本，发现启动方式为：Java –jar $jar\_file –Xms512m –Xmx1024m

**正确的Java命令:**

**java \[ options \] class \[ arguments \]**** **

**java \[ options \] -jar file.jar \[ arguments \]**

其实到这里，也找到了此问题原因所在，Java –jar $jar\_file –Xms512m –Xmx1024m被JVM解释成了程序的参数。

手动执行:    java –Xms512m –Xmx1024m –jar ems-client-1.0.jar

![1541751200606-12.png][]

至此，RES过高的问题已解决，但是VIRT的问题还在

使用系统命令pmap -x 3516查看进程的内存映射情况，会发现大量的64MB内存块存在；统计了下，大概有50多个65404+132=65536,正好是64MB，算起来大约3个多G

![1541751216035-13.png][]

于是Google之，发现大致的原因是从glibc2.11版本开始，linux为了解决多线程下内存分配竞争而引起的性能问题，增强了动态内存分配行为，使用了一种叫做arena的memory pool,在64位系统下面缺省配置是一个arena大小为64M，一个进程可以最多有cpu cores \* 8个arena。假设机器是8核的，那么最多可以有8 \* 8 = 64个arena，也就是会使用64 \* 64 = 4096M内存。

然而我们可以通过设置系统环境变量来改变arena的数量：

export MALLOC\_ARENA\_MAX=8（一般建议配置程序cpu核数）

配置环境变量使其生效，再重启该jvm进程，VIRT比之前少了快2个G:

![1541751239058-14.png][]

**/ ****具体的参考资料 /**

[https://access.redhat.com/documentation/enus/red\_hat\_enterprise\_linux/6/html/6.0\_release\_notes/compiler][https_access.redhat.com_documentation_enus_red_hat_enterprise_linux_6_html_6.0_release_notes_compiler]

[https://code.woboq.org/userspace/glibc/malloc/arena.c.html][https_code.woboq.org_userspace_glibc_malloc_arena.c.html]

**总结：**这里只是提供一种解决问题的思路，仅供参考；一般我们遇到问题之后， 首先想到的是不是程序有问题，然后跟踪了很久还是未找到问题根本原因；几经周折， 才发现问题是出现在最容易被我们忽视的地方（比如这里的脚本命令问题）！当然，每个公司或者每个人遇到的问题都不太一样，需要具体问题具体分析。

完整见：[https://www.analysys.cn/article/detail/20019016][https_www.analysys.cn_article_detail_20019016]

[1541750902773-1.png]: /images/20220417/86b557eb49d148eab7fe0579f33031ef.png
[1541750921931-2.png]: /images/20220417/68aa9b1e7d874241b498882bf5afdaf1.png
[1541750931906-3.png]: /images/20220417/1f692b9027be49a3bfb1edf39119dc7d.png
[1541750946493-4.png]: /images/20220417/1e066aafb79a47bf83b89003d6a407c9.png
[1541751012806-6.png]: /images/20220417/1e16e7a95cf345f3b078b791b23b7ae5.png
[1541751004593-7.png]: /images/20220417/6b792986abb64dc48999907c1e3476e7.png
[1541751093337-8.png]: /images/20220417/1d6607247a5846039f5dd3289f71aea4.png
[1541751102420-9.png]: /images/20220417/e9a157927a104e0f9c014eb621ac7668.png
[1541751112527-10.png]: /images/20220417/96399e04d29349f4a232731f275d2678.png
[1541751139421-11.png]: /images/20220417/976366e7f13f4bc19d19d670edb90e8c.png
[1541751200606-12.png]: /images/20220417/8225f1f9d61049f594f960c60e209bf9.png
[1541751216035-13.png]: /images/20220417/499aaa778eac4ef3aa49f15daefde5e8.png
[1541751239058-14.png]: /images/20220417/353627a433df4776b4339d3f92bb86d3.png
[https_access.redhat.com_documentation_enus_red_hat_enterprise_linux_6_html_6.0_release_notes_compiler]: https://access.redhat.com/documentation/enus/red_hat_enterprise_linux/6/html/6.0_release_notes/compiler
[https_code.woboq.org_userspace_glibc_malloc_arena.c.html]: https://code.woboq.org/userspace/glibc/malloc/arena.c.html
[https_www.analysys.cn_article_detail_20019016]: https://www.analysys.cn/article/detail/20019016