有关OOM问题

1、OOM类型

OOM，即OutOfMemory，内存溢出，原因是：分配的太少；用的太多；用完没释放。

内存泄漏：内存用完没有被释放。大量的内存泄漏就会导致OOM，也就是内存溢出。

常见的OOM情况有三种：

1. java.lang.OutOfMemoryError: Java heap space ------>java堆内存溢出，此种情况最常见，一般由于内存泄露或者堆的大小设置不当引起。对于内存泄露，需要通过内存监控软件查找程序中的泄露代码，而堆大小可以通过虚拟机参数-Xms,-Xmx等修改。
2. java.lang.OutOfMemoryError: PermGen space/ Metaspace------>java永久代（元数据）溢出，即方法区溢出了，一般出现于大量Class或者jsp页面，或者采用cglib等反射机制的情况，因为上述情况会产生大量的Class信息存储于方法区。此种情况可以通过更改方法区的大小来解决，使用类似-XX:PermSize/MetaspaceSize=64m -XX:MaxPermSize/MaxMetaspaceSize =256m的形式修改。另外，过多的常量也会导致方法区溢出。
3. java.lang.StackOverflowError ------>不会抛OOM error，但也是比较常见的Java内存溢出。JAVA虚拟机栈溢出，一般是由于程序中存在死循环或者深度递归调用造成的，栈大小设置太小也会出现此种溢出。可以通过虚拟机参数-Xss来设置栈的大小。

2、OOM处理

2.1 OutOfMemoryError: Java heap space异常（堆溢出）

将堆信息dump出来，进行分析，dump的方法有两种：

——设置JVM参数-XX:+HeapDumpOnOutOfMemoryError，设定当发生OOM时自动dump出堆信息。

——用JDK自带的jmap导出dump文件

导出hprof文件后，使用MAT进行内存镜像分析，MAT进行分析主要看4个界面：

HistoGram：列出内存中的对象，对象的个数和大小

Retained Heap比Shallow Heap多了当前对象引用的对象的Shallow Heap。

Dominator Tree：列出线程，以及线程下各对象占用的内存

通过Path to GC roots可以查看线程中完整的对象引用链

Top Consumers：通过图形列出最大的Object，便于定位问题

Leak Suspects：自动分析内存泄漏原因

导致堆内存泄漏的常见原因：

——静态集合类引起的内存泄漏：像HashMap、Vector等的使用最容易出现内存泄露，这些静态变量的生命周期和应用程序一致，他们所引用的所有的对象Object也不能被释放，因为他们也将一直被Vector等引用着。

——当集合Set里面的对象属性被修改后，再调用remove()方法时不起作用。之所以不起作用，是因为对象属性修改后，对象的hashcode就变了，remove的时候就找不到了。

——监听器。Listener未删除。

——各种连接。比如数据库连接、Socket连接、IO连接等，没有显式close掉。

——非静态内部类。非静态内部类会自动生成构造函数，并把外部类作为构造函数的参数，这样才能在内部类里使用外部类的属性和方法。但是这样内部类会保留外部类的引用，如果内部类与外部类的生命周期不一致，就可能回收不了。

——单例模式。在单例对象中引用了其它对象，被引用对象永远不会回收。

2.2 OutOfMemoryError: PermGen space/ Metaspace异常（方法区溢出）
方法区里面是类的类型信息，同样借助MAT分析Dump下来的内存镜像。

一般产生的原因：

——不正确地使用反射生成大量的Class

——有大量的JSP

——类中过多地使用常量

——对类加载器使用缓存

2.3 OutOfMemoryError:GC overhead limit exceeded
用98%的时间去GC，但只能回收2%的内存，说明内存已经没法回收了，很有可能是内存中的对象都是不可回收对象，导致无法GC。

2.4 StackOverflowError异常（栈溢出）
这一类是线程异常，处理的方法是使用jstack输出.out文件，然后分析每个线程栈的运行情况。

一般产生的原因：

——出现无限递归或死循环，局部变量不停地创建，导出栈溢出。

参考链接：https://www.jianshu.com/p/0744abda44cb