1、什么是OOM？ 

OOM，全称“Out Of Memory”，翻译成中文就是“内存用完了”，来源于java.lang.OutOfMemoryError。意思就是说，当JVM因为没有足够的内存来为对象分配空间并且垃圾回收器也已经没有空间可回收时，就会抛出这个error（注：非exception，因为这个问题已经严重到不足以被应用处理）。

2、为什么会OOM？

为什么会没有内存了呢？原因不外乎有两点：

（1）分配的少了：比如虚拟机本身可使用的内存（一般通过启动时的VM参数指定）太少。

（2）应用用的太多，并且用完没释放，浪费了。此时就会造成内存泄露或者内存溢出。

• 内存泄露：申请使用完的内存没有释放，导致虚拟机不能再次使用该内存，此时这段内存就泄露了，因为申请者不用了，而又不能被虚拟机分配给别人用。
• 内存溢出：申请的内存超出了JVM能提供的内存大小，此时称之为溢出。

在之前没有垃圾自动回收的日子里，比如C语言和C++语言，我们必须亲自负责内存的申请与释放操作，如果申请了内存，用完后又忘记了释放，比如C++中的new了但是没有delete，那么就可能造成内存泄露。偶尔的内存泄露可能不会造成问题，而大量的内存泄露可能会导致内存溢出。

而在Java语言中，由于存在了垃圾自动回收机制，所以，我们一般不用去主动释放不用的对象所占的内存，也就是理论上来说，是不会存在“内存泄露”的。但是，如果编码不当，比如，将某个对象的引用放到了全局的Map中，虽然方法结束了，但是由于垃圾回收器会根据对象的引用情况来回收内存，导致该对象不能被及时的回收。如果该种情况出现次数多了，就会导致内存溢出，比如系统中经常使用的缓存机制。Java中的内存泄露，不同于C++中的忘了delete，往往是逻辑上的原因泄露。

3、OOM的类型

（1）JVM内存模型：

按照JVM规范，JAVA虚拟机在运行时会管理以下的内存区域：

• 程序计数器：当前线程执行的字节码的行号指示器，线程私有
• JAVA虚拟机栈：Java方法执行的内存模型，每个Java方法的执行对应着一个栈帧的进栈和出栈的操作。
• 本地方法栈：类似“ JAVA虚拟机栈 ”，但是为native方法的运行提供内存环境。
• JAVA堆：对象内存分配的地方，内存垃圾回收的主要区域，所有线程共享。可分为新生代，老生代。
• 方法区：用于存储已经被JVM加载的类信息、常量、静态变量、即时编译器编译后的代码等数据。Hotspot中的“永久代”。
• 运行时常量池：方法区的一部分，存储常量信息，如各种字面量、符号引用等。
• 直接内存：并不是JVM运行时数据区的一部分， 可直接访问的内存， 比如NIO会用到这部分。

按照JVM规范，除了程序计数器不会抛出OOM外，其他各个内存区域都可能会抛出OOM。

（2）OOM的情况

最常见的OOM情况有下面的前三种：

1）java.lang.OutOfMemoryError: Java heap space ------>java堆内存溢出

此种情况最常见，一般由于内存泄露或者堆的大小设置不当引起。对于内存泄露，需要通过内存监控软件查找程序中的泄露代码，而堆大小可以通过虚拟机参数-Xms,-Xmx等修改。

发生堆内存不足的原因可能有：

• 设置的堆内存太小，而系统运行需要的内存要超过这个设置值
• 内存泄露。关注系统稳定运行期，full gc每次gc后的可用内存值是否一直在增大。
• 由于设计原因导致系统需要过多的内存，如系统中过多地缓存了数据库中的数据，这属于设计问题，需要通过设计减少内存的使用。
• 分析线程执行模型和它们持有的JVM里的短生命对象，例如：GC效率低下。

GC效率低下引起的OOM

如果堆空间小，那GC所占时间就多，回收所释放的内存不会少。根据GC占用的系统时间，以及释放内存的大小，虚机会评估GC的效率，一旦虚机认为GC的效率过低，就有可能直接抛出OOM异常。但这个判定不会太随意。

一般虚机会检查几项：

  ● 花在GC上的时间是否超过了98%

  ● 老年代释放的内存是否小于2%

  ● eden区释放的内存是否小于2%

  ● 是否连续最近5次GC都出现了上述几种情况（注意是同时出现）

只有满足所有条件，虚机才会抛出OOM：GC overhead limit exceeded

这个只是辅助作用，帮助提示系统分配的堆可能大小，并不强制开启。有关闭开关-XX:-UseGCOverheadLimit来禁止这种。

2).java.lang.OutOfMemoryError: PermGen space（JAVA8引入了Metaspace区域） ------>java永久代溢出

即方法区溢出了，一般出现于大量Class或者jsp页面，或者采用cglib等反射机制的情况，因为上述情况会产生大量的Class信息存储于方法区。此种情况可以通过更改方法区的大小来解决，使用类似-XX:PermSize=64m -XX:MaxPermSize=256m的形式修改。另外，过多的常量尤其是字符串也会导致方法区溢出。

A.常量池（JDK1.6,JDK1.7以后常量池不会放在永久代中了。）

string常量对象会在常量池（包含类名，方法名，属性名等信息）中以hash方式存储和访问，hash表默认的大小为1009，当string过多时，可以通过修改-xx:stringtableSize参数来增加Hash元素的个数，减少Hash冲突。

B.class加载

由于class被卸载的条件十分的苛刻，这个class所对应的classLoader下面所有的class都没有活对象的应用才会被卸载。

方法区（Method Area）不仅包含常量池，而且还保存了所有已加载类的元信息。当加载的类过多，方法区放不下所有已加载的元信息时，就会抛出OutOfMemoryError: PermGen space异常。主要有以下场景： 

• 使用一些应用服务器的热部署的时候，会遇到热部署几次以后发现内存溢出了，这种情况就是因为每次热部署的后，原来的class没有被卸载掉。

• 如果应用程序本身比较大，涉及的类库比较多，但分给永久代的内存（-XX:PermSize和-XX:MaxPermSize来设置）比较小的时候也可能出现此种问题。

解决方法：在每次CGlib动态创建时，都重新给它设置一个classLoader,这样在运行代码就不会出现OOM,会发现大量的class被卸载。

加+PrintGCDetails参数，打印日志可看地gc情况。+TraceClassUnloading，查看日志。  

3).java.lang.StackOverflowError ------> 不会抛OOM error，但也是比较常见的Java内存溢出。

JAVA虚拟机栈溢出，一般是由于程序中存在死循环或者深度递归调用造成的，栈大小设置太小也会出现此种溢出。可以通过虚拟机参数-Xss来设置栈的大小。

与线程栈相关的内存异常有两个：

• StackOverflowError(方法调用层次太深，内存不够新建栈帧)

• OutOfMemoryError（线程太多，内存不够新建线程）

(1).通常都是程序的问题，JVM对栈帧的大小设置已经很大了。

(2).程序运行过程中，方法分派时，会分配frame来存放本地变量，栈,pc寄存器等信息，方法再调用方法会导致Java栈空间无止境的增长（死递归），Java的解决方法是：设置一个私有栈（不在堆内存，而是在NativeMemory），这个栈的空间大小，通过-Xss来设置，数量级在256K-1MB。如果使用空间超过了-Xss限制，请求新建栈帧时，栈所剩空间小于栈帧所需空间，就会出现StackOverflowError。

(3).死递归。死递归和死循环的区别：死循环类似于while（true）的操作，它的线程栈空间使用不会递增。而死递归需要记录退回的路径，递归过程中调用方法，每个方法运行过程中的本地变量。也就是要记录上下文信息。这些信息会随着内容的增加，占用很大的内存空间。

例如:

• a.组件的复用。

• b.子类调用父类（复用父类的方法），父类调用子类（达到多态的效果），这中间要经过许多方法，可能形成环，进而形成死递归。

• c.三方框架的问题。

4)：java.lang.OutOfMemoryError: Metaspace

JDK1.7中，存储在永久代的部分数据就已经转移到了Java Heap或者是 Native Heap，譬如符号引用(Symbols)转移到了native heap；字面量(interned strings)转移到了java heap；类的静态变量(class statics)转移到了java heap。但永久代仍存在于JDK1.7中，并没完全移除。 

JDK 8.HotSpot JVM使用本地化的内存存放类的元数据，这个空间叫做元空间（Metaspace）。官方定义：”In JDK 8, classes metadata is now stored in the native heap and this space is called Metaspace”。元空间的本质和永久代类似，都是对JVM规范中方法区的实现。不过元空间与永久代之间最大的区别在于：元空间并不在虚拟机中，而是使用本地内存。因此，默认情况下，元空间的大小仅受本地内存限制，但可以通过以下参数来指定元空间的大小：-XX:MetaspaceSize、-XX:MaxMetaspaceSize。 

5).OutOfMemoryError: Direct buffer memory 

Java中普通I/O用输入/输出流方式实现，输入流InputStream（终端—>直接内存->JVM），输出流（JVM->直接内存->终端），这一过程中有kenel与JVM之间的拷贝（很多次），为了使用直接内存，Java是有一块区域叫DirectBuffer，不是JavaHeap而是cHeap的一部分。

NIO支持直接内存的使用，也就是通过java代码，获得一块堆外的内存空间，这块空间是直接向操作系统申请的。它的申请速度比堆内存慢，但访问速度快。
对于那些可复用的，并会被经常访问的空间，使用直接内存可提高系统性能。但由于直接内存没有被java虚机完全托管，若使用不当，也容易触发溢出，导致宕机。

ByteBuffer有两种一种是heap ByteBuffer,该类对象分配在JVM的堆内存里面，直接由Java虚拟机负责垃圾回收，一种是direct ByteBuffer是通过jni在虚拟机外内存中分配的。direct ByteBuffer可以通过-XX:MaxDirectMemorySize来设置，此参数的含义是当Direct ByteBuffer分配的堆外内存到达指定大小后，即触发Full GC。

4.OOM分析--heapdump

要dump堆的内存镜像，可以采用如下两种方式：

• 设置JVM参数-XX:+HeapDumpOnOutOfMemoryError，设定当发生OOM时自动dump出堆信息。不过该方法需要JDK5以上版本。
• 使用JDK自带的jmap命令。"jmap -dump:format=b,file=heap.bin <pid>"   其中pid可以通过jps获取。

dump堆内存信息后，需要对dump出的文件进行分析，从而找到OOM的原因。常用的工具有：

• mat: eclipse memory analyzer, 基于eclipse RCP的内存分析工具。详细信息参见：http://www.eclipse.org/mat/，推荐使用。   
• jhat：JDK自带的java heap analyze tool，可以将堆中的对象以html的形式显示出来，包括对象的数量，大小等等，并支持对象查询语言OQL，分析相关的应用后，可以通过http://localhost:7000来访问分析结果。不推荐使用，因为在实际的排查过程中，一般是先在生产环境 dump出文件来，然后拉到自己的开发机器上分析，所以，不如采用高级的分析工具比如前面的mat来的高效。

这个链接：http://www.ibm.com/developerworks/cn/opensource/os-cn-ecl-ma/index.html中提供了一个采用mat分析的例子 。

注意：因为JVM规范没有对dump出的文件的格式进行定义，所以不同的虚拟机产生的dump文件并不是一样的。在分析时，需要针对不同的虚拟机的输出采用不同的分析工具（当然，有的工具可以兼容多个虚拟机的格式）。IBM HeapAnalyzer也是分析heap的一个常用的工具。

5、推荐相关文章

（1）https://segmentfault.com/a/1190000019910501