java处理oom_Java中常见的几个OOM异常的情况以及处理思路总结

除了PC(程序计数器)以外，Java虚拟机内存区域的都有可能发生OOM(OutOfMemoryError)。

Java堆溢出

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

解决思路

一般的手段是：先通过内存映像工具对Dump出来的堆转储快照进行分析，重点是确认内存中的对象是否是必要的，也就是要先分清楚到底是出现了内存泄漏还是内存溢出。

如果是内存泄漏，可进一步通过工具查看泄漏对象到GC Roots的引用链。这样就能够找到泄漏的对象是通过怎么样的路径与GC Roots相关联的导致垃圾回收机制无法将其回收。掌握了泄漏对象的类信息和GC Roots引用链的信息，就可以比较准确地定位泄漏代码的位置。

如果不存在泄漏，换句话说，就是内存中的对象确实必须存活着，那么此时就需要通过虚拟机的堆参数( -Xmx和-Xms)来适当调大参数；从代码上检查是否存在某些对象存活时间过长、持有时间过长的情况，尝试减少运行时内存的消耗。

-Xmx : 最大堆空间；

-Xms : 初始堆空间大小，如果初始堆空间耗尽，JVM会对堆空间扩容，其扩展上限为最大堆空间。通常-Xms与-Xmx设置为同样大小，避免扩容造成性能损耗。

虚拟机栈和本地方法栈溢出

由于在HotSpot虚拟机上并不区分虚拟机栈和本地方法栈，因此栈容量只能由-Xss参数设定。在Java虚拟机规范中描述了两种异常：

StackOverflowError ：如果线程请求的栈深度超过了虚拟机所允许的最大深度，就会抛出该异常；

OutOfMemoryError：如果虚拟机在拓展栈的时候，无法申请到足够的空间，就会抛出该异常。

对于这两种异常来说，存在着一些互相重叠的地方：当栈空间无法继续分配的时候，到底是内存太小还是已使用的栈空间太大，其实只是对同一件事情的两种描述罢了。

当在单线程环境下，无论是由于栈帧太大还是虚拟机栈容量太小，当内存无法继续分配的时候，虚拟机抛出的都是StackOverflowError 异常。

在多线程环境下，如果为每个线程的栈分配的内存越大，反而越容易产生OOM异常。每个线程分配到的栈容量越大，可以建立的线程数量就自然减少了，那么在新建立线程的时候就很容易把内存耗尽，产生OOM异常。虚拟机默认参数栈深度大多数情况下能够达到1000~2000，对于正常的方法调用(包括递归)是完全够用的。但是，在多线程环境下的OOM，就只能通过减少最大堆和减少栈容量来换取更多的线程数量。

方法区和运行时常量池溢出

方法区用于存放Class的相关信息，如类名、访问修饰符、常量池、字段描述、方法描述等。当前的一些主流框架，如Spring、Hibernate，对于类进行增强的时候都会使用到CGLib这类字节码技术，增强的类越多，就需要越大的方法区来保证动态生成Class可以加载入内存，这样的情况下可能会造成方法区的OOM异常。

在经常动态生成大量Class的应用中，需要特别注意类的回收状况。这类场景还在：大量JSP或动态生成JSP文件的应用(JSP第一次运行时需要编译为Java类)、基于OSGi的应用(即使是同一个类文件，被不同的加载器加载也会视作不同的类)等。

直接内存溢出

直接内存(DirectMemory)容量可以通过-XX : MaxDirectMemorySize指定，如果不指定，则默认与Java最大堆(-Xmx指定)一样。

由于直接内存(DirectMemory)导致的内存溢出，一个明显的特征是在Heap Dump文件中不会看见明显的异常，如果发现OOM之后Dump文件很小，而程序中又直接或间接使用了NIO，就可以考虑检查一下是否为直接内存(DirectMemory)溢出异常。

参考资料