Java：Jvm之 jmap+mat实战内存溢出

前言

JDK本身自带几个十分有用的命令，可以监控java进程、查看内存和GC、加载类的个数等等，这里我们会先介绍几个命令，然后制造一个内存溢出的场景来进行实战分析。

命令

1、jps -l

查出当前服务器运行的java进程

2、jinfo

1）、查看最大堆内存

jinfo -flag MaxHeapSize 23789(进程ID)

比如查出1中的tomcat的最大堆内存设置：

2）、查看手动修改过的参数

jinfo -flags 23789(进程ID)

有些是我们自己设置的，有些是tomcat的shell脚本自己设置的:

3）、查看GC垃圾回收器

jinfo -flag UseConcMarkSweepGC 3176

jinfo -flag UseG1GC 3176

jinfo -flag UseParallelGC 3176

3、jstat

1）、查看类加载的个数

jstat -class 23789

2）、打印gc结果

每个一秒打印一次23789进程的gc结果，共打印10次。

jstat -gc 23789 1000 10

输出结果解释：

S0C、S1C、S0U、S1U：S0和S1的总量与使用量

EC、EU：Eden区总量与使用量

OC、OU：Old区总量与使用量

MC、MU：Metaspace区总量与使用量

CCSC、CCSU：压缩类空间总量与使用量

YGC、YGCT：YoungGC次数与时间

FGC、FGCT：FullGC的次数与时间

GCT：总的GC时间

3）、查看编译的文件数

jstat -compiler 29600

查看编译的文件数，失败多少、用时多少等等

模拟场景

分别制造堆内存溢出和metaspace内存溢出，在启动参数中设置为32M。

分析映像文件

1、设置内存溢出自动导出

VM中加入如下两个参数，第二个表示映像文件存放在当前目录。

-XX:+HeapDumpOnOutOfMemoryError

-XX:HeapDumpPath=./

2、jmap导出映像文件

1）、jps -l 查看pid

2）、格式化dump文件

jmap -dump:format=b,file=heap.hprof 10776

format表示格式化，file表示文件名称，10776是pid。

3、分析映像文件

使用MAT分析映像文件

下载地址：https://www.eclipse.org/mat/downloads.php

下载后解压即可，就是这么个玩意：

打开open-file，然后可以看到：图表显示，以及下方的问题明细。

还可以，点击上方菜单图标第二个，查看对象数量：

可以直接用正则来查看某个包里产生对象数量：

可以发现，User对象生成数量最多：

右键mergeXXX-排除虚引用，只显示强引用：

就可以看到具体的对象占用信息：

同理，
还可以，点击上方菜单图标第三个，查看对象所占内存：

可以看到，第一个占用最多：

同上，右键打开查看强引用：

总结

就个人在实际工作当中的体会，内存溢出发生的概率其实没那么大，一旦出现往往都是由于以下几个方面导致：

1）、代码编写不规范，某些循环或其它业务逻辑导致生成大量实例；

2）、服务器分配内存不达标，这个遇到的其实最多。



  PS：以我前公司的某大型电网客户为例，他们的服务器都是自己机房分配的(有钱)，应用服务器的内存往往32G起步，64G常规，我们按照一套标准为服务器分配堆内存，首先，服务器上尽量不装其他软件，只部署应用服务，让内存得到最大利用，其次，分配服务器完整内存的70%-80%为该应用服务的堆内存，64G的话大概就分配45G-52G左右，几年下来其实从未出现过堆内存溢出的问题。

当然，这不是绝对的，但充分说明了在代码层面稳定的情况下，解决客观堆内存溢出最香的方式就是……钱。

---

本人原创文章纯手打，觉得有一滴滴帮助的话就请伸出纤纤玉手点个赞和收藏吧 ~ ^_

---

其他文章：https://mp.weixin.qq.com/s/_od14WO6KFjKiwNb6S8TWw