JVM系列(2)- jmap+mat实战内存溢出

熟悉几个监控JVM的常用命令

1. jps -l

查出当前服务器运行的java进程
1755845-20190730134946613-578976702.png
---

2. jinfo用法(结合jps -l查到进程ID)

1)、查看最大堆内存:jinfo -flag MaxHeapSize 23789(进程ID)
比如查出1中的tomcat的最大堆内存设置:
1755845-20190730135021352-1594808403.png

2)、查看手动修改过的参数:jinfo -flags 23789(进程ID)
有些是我们自己设置的,有些是tomcat的shell脚本自己设置的:
1755845-20190730135054928-85194443.png

3)、查看GC垃圾回收器:
jinfo -flag UseConcMarkSweepGC 3176
jinfo -flag UseG1GC 3176
jinfo -flag UseParallelGC 3176
1755845-20190730135115880-377665803.png
***

3. jstat用法

1)、jstat -class 23789:查看类加载的个数
1755845-20190730135147305-1015463123.png

2)、jstat -gc 23789 1000 10:每个一秒打印一次23789进程的gc结果,共打印10次。
1755845-20190730135206984-718607906.png

输出结果解释:
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:查看编译的文件数,失败多少、用时多少等等
1755845-20190730135232030-1772872581.png
----

制造一个内存溢出场景

分别制造堆内存溢出和metaspace内存溢出,在启动参数中设置为32M。
1755845-20190730135258126-2006715616.png
----

导出内存映像文件

1. 内存溢出自动导出,VM中加入如下两个参数,第二个表示映像文件存放在当前目录。

-XX:+HeapDumpOnOutOfMemoryError
-XX:HeapDumpPath=./
----

2. jmap导出映像文件

1)、jps -l 查看pid
1755845-20190730135524466-1009913574.png

2)、jmap -dump:format=b,file=heap.hprof 10776
format表示格式化,file表示文件名称,10776是pid。
1755845-20190730135549810-1254110331.png
1755845-20190730135604577-329094282.png
----

使用MAT分析映像文件

下载地址: https://www.eclipse.org/mat/downloads.php
1755845-20190730135645472-1624231227.png
----
下载后解压即可,就是这么个玩意:
1755845-20190730135711097-1676787609.png
----
打开open-file,然后可以看到:图表显示,以及下方的问题明细。
1755845-20190730135731968-429876857.png
----
还可以,点击上方菜单图标第二个,查看对象数量:
1755845-20190730135752303-247900060.png
----
可以直接用正则来查看某个包里产生对象数量:
1755845-20190730135814914-1243026026.png
----
可以发现,User对象生成数量最多:
1755845-20190730135835781-1393194773.png
----
右键mergeXXX-排除虚引用,只显示强引用:
1755845-20190730135857573-187865886.png
----
就可以看到具体的对象占用信息:
1755845-20190730135915994-1337949383.png
----
同理,
还可以,点击上方菜单图标第三个,查看对象所占内存:
1755845-20190730135937014-624621203.png
----
可以看到,第一个占用最多:
1755845-20190730135958309-1149341486.png
----
同上,右键打开查看强引用:
1755845-20190730140018865-2104823771.png
----

个人心得

就个人在实际工作当中的体会,内存溢出发生的概率其实没那么大,一旦出现往往都是由于以下几个方面导致:
1)、代码编写不规范,某些循环或其它业务逻辑导致生成大量实例;
2)、服务器分配内存不达标,这个遇到的其实最多。

PS:以我前公司的某大型电网客户为例,他们的服务器都是自己机房分配的(有钱),应用服务器的内存往往32G起步,64G常规,我们按照一套标准为服务器分配堆内存,首先,服务器上尽量不装其他软件,只部署应用服务,让内存得到最大利用,其次,分配服务器完整内存的70%-80%为该应用服务的堆内存,64G的话大概就分配45G-52G左右,几年下来其实从未出现过堆内存溢出的问题。
当然,这不是绝对的,但充分说明了在代码层面稳定的情况下,解决堆内存溢出最好的方式就是……有钱。→_→


转载于:https://www.cnblogs.com/fulongyuanjushi/p/11269536.html

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值