JVM中各个区域内存都是有限的，在内存不足的情况下，继续分配新的内存空间，而不对老的内存空间进行回收释放，测试就会产生内存溢出，即大名鼎鼎的OOM(Out Of Memory).
1. 产生OOM的区域
在JVM的五大区域（堆、Java虚拟机栈、本地方法栈、Metaspace、程序计数器）中，独有程序计数器不会发生OOM，其他区域都会产生OOM，这是由于程序计数器中存储的数据所占空间的大小不会随程序的执行而发生改变。所以，会导致OOM产生的区域是：
- 堆，存放新创建的对象
- Java虚拟机栈，存放栈帧、方法局部变量。
- 本地方法栈
- Metaspace， 主要用来存放类的字节码信息
2. 解决OOM的思路
首先，需要确认一点的是配置没有剑走偏锋，不存在某个区域给的内存太小，正常情况下就容易产生OOM。这点很容易做到，先看下服务器的JVM配置，然后再和推荐的配置进行比较。
服务器上的JVM配置，可以通过jinfo -flags 进程号来查看，具体可以参考：JVM参数简介
。而推荐的配置可以通过PerfMa社区提供的XXFox产品来获取，XXFox有个根据机器配置一键生成JVM参数的功能，示意图如下：
如果JVM的内存配置看起来是合理的，那我们就需要定位到底是哪个对象生成太多导致了OOM。而想要知道哪个对象太多，我们就要获取发生OOM时的内存快照文件（即dump文件），只需要在JVM的启动参数中加入以下参数：
-XX:+HeapDumpOnOutOfMemoryError
-XX:HeapDumpPath=/usr/local/oom
-XX:+HeapDumpOnOutOfMemoryError表示在发生OOM的时候自动将内存快照dump出来， -XX:HeapDumpPath=/usr/local/oom参数指定dump文件存储的路径。
有了内存快照之后，我们就可以通过MAT之类的工具进行分析。关于MAT的使用可以参考：JVM堆内存分析工具-MAT
3. Java虚拟机栈的OOM
每个线程运行时，都会创建对应的虚拟机栈，线程中运行一个方法会创建一个栈帧，并将该栈帧入栈，方法执行结束则栈帧出栈。
一个线程的虚拟机栈内存大小一般设置成1M, 假如程序不停的创建栈帧并入栈（即发生方法调用），那么就有可能出现内存溢出的情况。一般而言，当发生递归调用，容易产生虚拟机栈的OOM。 以下程序模拟产生虚拟机栈的OOM
/**
* vm args:
* -XX:ThreadStackSize=1m
* @author zhangguicong
* @date 2019-12-23
*/
public class StackOomSample {
private static long counter = 0 ;
public static void main(String[] args) {
call();
}
private static void call () {
counter++;
System.out.println("第"+counter+"次调用call方法");
call();
}
}
解决办法
对线程的栈内存和栈帧来说，它们是不存在GC，所以没发通过查看GC日志来定位此类问题。另外，内存快照对此也无法提供帮助。
一般而言，只要把所有的异常都写入本地日志文件中，那么当系统发生问题时我们直接去看日志文件中的异常信息就可以。栈内存溢出的报错日志是：
Exception in thread "main" java.lang.StackOverflowError
4. Metaspace的OOM
Metaspace即JDK1.8之前常说的方法区，JVM运行过程中会不停地往这个区域加载类。当Metaspace区域快要满了，会触发一次Full GC， 而在每次Full GC的时候也会尝试回收Metaspace区域。Metaspace中class对象想要被回收，需要满足以下条件：
- 所有由该class创建出来的对象都已经被回收；
- class对象没有引用执行；
- 这个类的类加载器要先被回收。
因为有了以上条件的限制，所有class对象一般很难被回收掉。
Metaspace一般极少发生OOM，如果真的发生了，请考虑以下两种诱因。
- Metaspace内存空间设置很小。一般不进行配置的话，默认只有几十M，对于大型项目，可能要加载的类很多，所以可能会不够，一般而言，可以设置成512M；
- 系统中使用动态类加载技术（如，cglib）不当，导致动态生产的类过多。以下代码模拟产生Metaspace的OOM
import net.sf.cglib.proxy.Enhancer;
import net.sf.cglib.proxy.MethodInterceptor;
import net.sf.cglib.proxy.MethodProxy;
import java.lang.reflect.Method;
/**
* VM args:
* -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:MetaspaceSize=10m -XX:MaxMetaspaceSize=10m -XX:+PrintGCDetails -Xloggc:gc.log -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=./
* @author zhangguicong
* @date 2019-12-23
*/
public class MetaspaceOomSample {
public static void main(String[] args) {
dynamicCreateClass();
}
public static void dynamicCreateClass () {
while(true) {
Enhancer enhancer = new Enhancer();
enhancer.setSuperclass(Dog.class);
enhancer.setUseCache(false);
enhancer.setCallback(new MethodInterceptor() {
@Override
public Object intercept(Object o, Method method, Object[] objects, MethodProxy methodProxy) throws Throwable {
if (method.getName().equals("eat")) {
System.out.println("play with dog before dog eat.");
}
return methodProxy.invokeSuper(o,objects);
}
});
Dog dog = ((Dog) enhancer.create());
dog.eat();
}
}
static class Dog {
public void eat () {
System.out.println("dog is eating bone");
}
}
}
5. 堆的OOM
对于虚拟机栈和Metaspace区域来说，一般只要代码上注意一些，不太容易引发这两块区域的OOM。日常开发中，更常见的是堆内存中的OOM。
我们知道在堆内存中，对象首先存放在新生代中，发生YoungGC之后可能进入老年代，老年内存不足时再发生Full GC，但如果Full GC之后，发现对象依然需要存活，无法将其内存释放掉，此时老年代无法再放入新的对象，JVM只能选择内存溢出。
发生堆内存溢出的场景：
-
高并发，系统承载请求量过大，导致大量对象都是存活的，无法放入新的对象； - 系统存在
内存泄漏的问题，莫名其妙弄了很多的对象，没有及时取消对他们的引用，结果对象都是存活的，导致触发GC无法回收。
以下代码模拟产生堆的OOM
/**
* vm args:
* -Xms10m -Xmx10m -XX:+PrintGCDetails -Xloggc:gc.log -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=./ -XX:+UseParNewGC -XX:+UseConcMarkSweepGC
* @author zhangguicong
* @date 2019-12-23
*/
public class HeapOomSample {
public static void main(String[] args) {
List<Person> personList = new ArrayList<>();
while (true) {
personList.add(new Person("zs",23));
}
}
static class Person {
private String name;
private Integer age;
public Person(String name, Integer age) {
this.name = name;
this.age = age;
}
}
}
MAT分析dump文件
我们运行上面的示例代码，不一会生成dump文件，使用MAT打开这个dump文件，可以看到如下图所示：
点击Leak Suspects，MAT给我们推测出来发生OOM的原因只有一个：
我们看高亮部分的英文提示：main线程通过局部变量引用了96.98%的对象，且都被java.lang.Object[]的一个实例对象引用着。此时我们并不能知道Object[]中是什么东西，需要点击 Details 》，点击之后，我们可以看到：
到这里，我们可以知道OOM产生的原因是堆内存中产生了大量的Person对象导致的。
此外我们还可以点击“See stacktrace”查看线程的执行栈情况，定位到可能发生OOM的代码所在位置：
