5：实战：内存溢出的定位与分析
内存溢出在日常工作中，这个错误很容易遇到。遇到内存溢出，首先我们需要快速定位内存溢出的环节(位置)，需要进行分析，看看是正常情况还是非正常情况。如果是正常情况，这个时候我们需要加大内存。如果是非正常情况，就需要对我们的程序进行修改，来修复这个问题。
首先，我们需要学会如何定位问题，然后在对问题进行分析，如何定位问题？这里我们可以借助于jmap与MAT工具进行分析。
5.1：模拟内存溢出
场景：
我们向list集合中添加100W个字符串，每个字符串再由100个UUID组成。如果可以正常执行，最后打印出OK。
/**
* Created by kaigejava on 2019/7/3.
*模拟内存溢出的
*/
@Slf4j
public class TestJvmOutOfMemory {
/**
* 内存溢出
*/
@Test
public void jvmOutOfMemoryTest(){
List<Object> list = new ArrayList<>();
for (int i = 0; i < 10000000; i++) {
System.out.println(i);
String str = "";
for (int j = 0; j < 1000; j++) {
str += UUID.randomUUID().toString();
}
list.add(str);
}
System.out.println("ok");
}
}
设置程序运行的JVM内存大小:
Edit Configurations
设置VM options的值：-Xms6m -Xmx6m -XX:+HeapDumpOnOutOfMemoryError
设置完成之后，我们运行程序：
5.2：运行内存溢出程序
我们发现当外出循环i=50的时候就发生了内存溢出。
错误文件：Dumping heap to java_pid14200.hprof
我们借助于：Everything快速找到文件。
导入到MAT中，进行分析。
5.3：导入MAT中，进行分析
导入分析后，我们发现77.37%也就是4.6MB都被java.lang.object[]数组占用了。
经过分析，我们发现这个object数组占用这么大，很可疑，这个就有可能是导致内存溢出的原因。
在接着查看详情：
我们发现集合中存放了大量的UUID数据。符合我们的测试。达到了我们的实验目的。
本实验只是为了模拟内存溢出，怎么分析问题。
在下一个阶段中，我们将要学习怎么查看JVM中的线程执行情况。
6：jstack的使用
有些时候，我们需要查看下JVM中的线程执行情况。比如，发现服务器的CPU负荷突然增高了，出现了死锁、死循环等情况，这些情况下，我们又该如何分析呢？
由于程序是正常运行的，没有任意异常输出，从日志方面也看不出什么问题的，所以就需要查看JVM的内部线程执行情况了，然后再进行分析查找原因。
这个时候，就需要借助另外一个命令了：jstack命令。
Jstack的作用是将正在运行的JVM的线程进行快照，并打印出来。
本文来源：http://www.kaigejava.com/article/detail/467
凯哥个人博客：www.kaigejava.com
凯哥公众号：凯哥Java(kaigejava)
网友评论