![ef18a172e3b9ad12b8b4d0f0e0b4681b.png](https://i-blog.csdnimg.cn/blog_migrate/ac45df0b2f7c3786213d3d50b90820a7.jpeg)
熟悉几个监控JVM的常用命令
1. jps -l
查出当前服务器运行的java进程
![5c44a9b7707a2720c7030ef515f34daf.png](https://i-blog.csdnimg.cn/blog_migrate/e017194d88218822674915c534639f95.jpeg)
2. jinfo用法(结合jps -l查到进程ID)
1)、查看最大堆内存:jinfo -flag MaxHeapSize 23789(进程ID)
比如查出1中的tomcat的最大堆内存设置:
![4a73fbf177dee10dfb01d6286c82486f.png](https://i-blog.csdnimg.cn/blog_migrate/9c7fd3a2cc704e04d380c00f1f4bbddd.png)
2)、查看手动修改过的参数:jinfo -flags 23789(进程ID)
有些是我们自己设置的,有些是tomcat的shell脚本自己设置的:
![68b43cacb17385f8a30d0693b8af9f3e.png](https://i-blog.csdnimg.cn/blog_migrate/c6243dde7718acb6894dec7ea813f838.png)
3)、查看GC垃圾回收器:
jinfo -flag UseConcMarkSweepGC 3176
jinfo -flag UseG1GC 3176
jinfo -flag UseParallelGC 3176
![3fbf5adbd8339cc3b1abbb29d4cda5f4.png](https://i-blog.csdnimg.cn/blog_migrate/761e89177248e8bb6302b7e932eda71f.jpeg)
3. jstat用法
1)、jstat -class 23789:查看类加载的个数
![b9f4b2fa0b7076523b8a65778dad404c.png](https://i-blog.csdnimg.cn/blog_migrate/fb7eb449b8510d7ef988610b192f36f0.jpeg)
2)、jstat -gc 23789 1000 10:每个一秒打印一次23789进程的gc结果,共打印10次。
![b2b1696a30b73c2df3bf72af087fe249.png](https://i-blog.csdnimg.cn/blog_migrate/b6a916b6dee1370d0014253d5fb59ca2.jpeg)
输出结果解释:
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:查看编译的文件数,失败多少、用时多少等等
![43ab30f5a8aa3a8655dd7ebd241f1097.png](https://i-blog.csdnimg.cn/blog_migrate/73b2caffefeed3100d410ebe089afd90.png)
制造一个内存溢出场景
分别制造堆内存溢出和metaspace内存溢出,在启动参数中设置为32M。
![12c000050ebe325cf043b2d22664cbbe.png](https://i-blog.csdnimg.cn/blog_migrate/5590b2b8e823e0ca8a32b8dbd87e38ef.jpeg)
导出内存映像文件
1. 内存溢出自动导出,VM中加入如下两个参数,第二个表示映像文件存放在当前目录。
-XX:+HeapDumpOnOutOfMemoryError
-XX:HeapDumpPath=./
2. jmap导出映像文件
1)、jps -l 查看pid
![5856dbb71c128188baae483a8f555701.png](https://i-blog.csdnimg.cn/blog_migrate/245540e3f1422617fec079b9873393e2.jpeg)
2)、jmap -dump:format=b,file=heap.hprof 10776
format表示格式化,file表示文件名称,10776是pid。
![e814ffb745f345b662bdc2b721546a0e.png](https://i-blog.csdnimg.cn/blog_migrate/688b1e5c02b6dec4521f4ff751d996b9.jpeg)
![3543614be520d53c15ceddc815344d23.png](https://i-blog.csdnimg.cn/blog_migrate/9ad3ee1a3371e6a382da8ee8777664d1.jpeg)
使用MAT分析映像文件
下载地址:https://www.eclipse.org/mat/downloads.php
![802f3d139d71a16a10f57b4c6658ddc0.png](https://i-blog.csdnimg.cn/blog_migrate/275ee372732f67e658ad1481aa38f654.jpeg)
下载后解压即可,就是这么个玩意:
![01d3877f04c63fb628367ffc7a7a7796.png](https://i-blog.csdnimg.cn/blog_migrate/5224eff2c0ef9881bbf20a0c47d23725.jpeg)
打开open-file,然后可以看到:图表显示,以及下方的问题明细。
![2bf64cdfe286fa5f24d746f94fcad4e2.png](https://i-blog.csdnimg.cn/blog_migrate/50c6b51e34d131407f6d57fc0fd1e31c.jpeg)
还可以,点击上方菜单图标第二个,查看对象数量:
![19af643d9083ef9535877895f7d13a99.png](https://i-blog.csdnimg.cn/blog_migrate/3b44e9a4488c881c46ea4184dec6dd40.jpeg)
可以直接用正则来查看某个包里产生对象数量:
![490090a63f74d5788e7d12bbbb0a6f1b.png](https://i-blog.csdnimg.cn/blog_migrate/10ed6aea737964371d752f72168b30ba.jpeg)
可以发现,User对象生成数量最多:
![61f3a4d54a72af5308a556a4236ec8ac.png](https://i-blog.csdnimg.cn/blog_migrate/52b024ad0328f678edbde31ba890838e.jpeg)
右键mergeXXX-排除虚引用,只显示强引用:
![12045d8e4942c8e47ae4ac64b345821a.png](https://i-blog.csdnimg.cn/blog_migrate/0b312315f864955e32adef13b482e148.jpeg)
就可以看到具体的对象占用信息:
![b7f7422d12df446e5214b2751830f090.png](https://i-blog.csdnimg.cn/blog_migrate/e2802026912225ac4f8ff774376f9519.jpeg)
同理,
还可以,点击上方菜单图标第三个,查看对象所占内存:
![1277b2b735fecabf99a0a631432a0133.png](https://i-blog.csdnimg.cn/blog_migrate/181d7c2e6d569630b74dcb8547139501.jpeg)
可以看到,第一个占用最多:
![ce4a64c3ae23e7c1c4ec28c9ae9d4a41.png](https://i-blog.csdnimg.cn/blog_migrate/6fda233afc9baf468bee4a3ed770d3ba.jpeg)
同上,右键打开查看强引用:
![0f72e9e5e3b8ca3e337501034244dc3b.png](https://i-blog.csdnimg.cn/blog_migrate/fd481ebabaed37e15371dfd7cc57bafc.png)
个人心得
就个人在实际工作当中的体会,内存溢出发生的概率其实没那么大,一旦出现往往都是由于以下几个方面导致:
1)、代码编写不规范,某些循环或其它业务逻辑导致生成大量实例;
2)、服务器分配内存不达标,这个遇到的其实最多。
PS:以我前公司的某大型电网客户为例,他们的服务器都是自己机房分配的(有钱),应用服务器的内存往往32G起步,64G常规,我们按照一套标准为服务器分配堆内存,首先,服务器上尽量不装其他软件,只部署应用服务,让内存得到最大利用,其次,分配服务器完整内存的70%-80%为该应用服务的堆内存,64G的话大概就分配45G-52G左右,几年下来其实从未出现过堆内存溢出的问题。
当然,这不是绝对的,但充分说明了在代码层面稳定的情况下,解决堆内存溢出最好的方式就是……有钱。→_→