服务器之家

服务器之家 > 正文

JVM 心得 OOM时的堆信息获取方法与分析

时间:2021-01-20 14:09     来源/作者:Michael_Chong

jvm的框架知识了解之后,实际的项目里发生了oom异常的话,怎么获取以及分析异常信息后怎么分析呢。

这里稍微做一下归纳。

第一步,首先通过下面两个方法的任何一种,把发生oom时的heap信息dump下来。

有两个方法,通过设置可以把oom时的dump信息获取到:

1)方法1:在jvm的启动参数里添加如下命令

-xx:+heapdumponoutofmemoryerror

2)方法2:在jdk的安装目录下,找到bin目录,然后双击执行"jvisualvm.exe"

执行程序之后,在视图里可以看到正在执行的java程序和java线程id(pid:xxx)。

右键选中"在oom时生成dump"。

第二步,执行如下代码(本例使用方法1。如果使用方法2时需要先执行代码,再在jvirtualvm中选中java程序设置oom时生成dump):

代码的意义是每一次创建一个1*1024*1024大小的int数组。在while中循环,引起heap的outofmemory异常发生。

有一个小知识点共享下,map进行containskey的处理时,key如果是javabean对象,判断时使用的是对象的引用。所以每次判断都是新的对象。

最好key的数据类型定义为值类型等(string作为key时使用常量字符串对string赋值如string key ="key",不要用string key = new string(“key”)的形式,这样又变成了一个引用对象了)。

?
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
package com.chong.studyparalell.jvm.heap;
 
import java.util.hashmap;
import java.util.map;
 
public class heapleakage {
 
static class mapkey{
integer key;
mapkey(integer key){
this.key = key;
}
}
 
public static void main(string []args){
 
map<mapkey,integer[]> localmap = new hashmap();
while(true){
for(int i = 0;i<10;i++){
try{
thread.sleep(100);
}catch(exception e){
e.printstacktrace();
}
mapkey mapkey = new mapkey(new integer(i));
if(!localmap.containskey(mapkey)){
localmap.put(mapkey, new integer[1*1024*1024]);
}
}
}
}
}

日志如下:

?
1
2
3
4
5
6
javagent: call premain instrumentation for class sizeof
java.lang.outofmemoryerror: java heap space
dumping heap to java_pid31512.hprof ...
heap dump file created [491663234 bytes in 0.930 secs]
exception in thread "main" java.lang.outofmemoryerror: java heap space
at com.chong.studyparalell.jvm.heap.heapleakage.main(heapleakage.java:38)

第三步,在项目的classpath目录下确认"java_pidxxx.hprof"文件是否存在,正常情况下应该存在的。

在jvirtualvm中,点击"文件"->"装入"->选中上述hprof文件。

点击“类”tab页,通过"大小"排序,可以看出java.lang.integer占用了99%以上的空间。

双击这一行,可以进入进去看到,各个integer的具体内容。这里的目的是发生oom,所以integer的内容没有设值,进去可以发现值都是null。

JVM 心得 OOM时的堆信息获取方法与分析

JVM 心得 OOM时的堆信息获取方法与分析

JVM 心得 OOM时的堆信息获取方法与分析

那么实际的项目里,可以观看发生问题线程里哪些对象的一直是活着的,并且size远远超出预期,重点分析这些可疑对象。推测的方向:是否在循环里大量的实例化对象,加载db数据时一次加载了大量的数据,以及是否发生了内存泄露(如长生命周期的map和set,list中一直保存在大量的不再使用的对象引用。),以及静态变量的使用等。

后记:

通过这几天的jvm复习,以及oom发生时的dump分析,再次做项目时,头脑会更清晰一些。^-^
jvm告一段落了,接下来会发一些跟springboot和redis相关的学习心得。

原文链接:http://www.cnblogs.com/chongpf/p/7677973.html

标签:
JVM OOM 

相关文章

热门资讯

2020微信伤感网名听哭了 让对方看到心疼的伤感网名大全
2020微信伤感网名听哭了 让对方看到心疼的伤感网名大全 2019-12-26
Intellij idea2020永久破解,亲测可用!!!
Intellij idea2020永久破解,亲测可用!!! 2020-07-29
背刺什么意思 网络词语背刺是什么梗
背刺什么意思 网络词语背刺是什么梗 2020-05-22
苹果12mini价格表官网报价 iPhone12mini全版本价格汇总
苹果12mini价格表官网报价 iPhone12mini全版本价格汇总 2020-11-13
歪歪漫画vip账号共享2020_yy漫画免费账号密码共享
歪歪漫画vip账号共享2020_yy漫画免费账号密码共享 2020-04-07
返回顶部