重识JVM（三）：OOM异常的常见处理思路

1.堆溢出

Java 堆用于存储对象实例，只要不断增加对象，并且保证GC Roots 到对象之间有可达路径来避免垃圾回收机制清除这些对象，那么在对象数量达到最大堆的容量限制后就会产生OOM 异常。

要解决这个区域的异常，一般的手段是通过内存映像分析工具对dump 出来的堆转储快照进行分析，重点是确认内存中的对象是否是必要的，也就是要判断是出现来内存泄露（不必要）还是内存溢出（必要）。前者的话要进一步通过工具查看泄露对象到GC Roots 的引用链，就可以准确地定位出泄露代码地位置；后者的话可以调大虚拟机的堆参数（-Xms 和-Xmx），或者从代码上检查是否存在某些对象生命周期过长的问题。

2.栈溢出（虚拟机栈和本地方法栈）

对于HotSpot 来说，虽然-Xoss 参数（设置本地方法栈大小）存在，但实际上是无效的，栈容量只由-Xss 参数设定。关于虚拟机栈和本地方法栈，在JVM 规范中描述了两种异常：
1） 如果线程请求的栈深度大于虚拟机所允许的最大深度，将抛出StackOverflowError 异常。
2）如果虚拟机在扩展栈时无法申请到足够的内存空间，将抛出OutOfMemoryError 异常。

操作系统分配给每个进程的内存是有限制的，每个线程分配到的栈容量越大，可以建立的线程数量自然就越少，建立线程时就越容易把剩下的内存耗尽。如果线程过多导致SOF，可以通过减少最大堆和减少栈容量来换取更多的线程。

3.方法区溢出

注意Java8 下运行时常量池在堆中，所以运行时常量池过大会体现为OOM：heap，而在此以前是放在永久代中，体现为OOM：PermGen space。

方法区还存放Class 的相关信息，运行时产生大量的类也会导致方法区（Java8 中放在直接内存中）溢出。

4.直接内存溢出

直接内存可以使用-XX:MaxDirectMemorySize 指定，如果不指定，则默认与Java 堆最大值相同。

虽然使用DirectByteBuffer 分配内存也会抛出OOM 异常，但它抛出异常时并没有真正向OS申请分配内存，而是通过计算得知内存无法分配，于是手动抛出异常。真正申请内存的方法是unsafe.allocateMemory()。

5.内存泄露

1）非静态内部类
2）连接未关闭：比如数据库连接（dataSourse.getConnection()），网络连接(socket)和io 连接，除非显式的调用了其close（）方法将其连接关闭，否则是不会自动被GC 回收的。