内存溢出 (简称OOM)是指应用系统中存在无法回收的内存或使用的内存过多，最终使得程序运行要用到的内存大于能提供的最大内存。
就比如说，你的电脑只有32GB的内存，已经把这32GB的内存用完了，但是还在继续用，就会造成内存溢出。
1.java堆内存溢出
设置的jvm内存太小，对象所需内存太大，创建对象时分配空间，就会抛出这个异常。
解决方法:
首先，如果代码没有什么问题的情况下，可以适当调整-Xms和-Xmx两个jvm参数，使用压力测试来调整这两个参数达到最优值。
其次，尽量避免大的对象的申请，像文件上传，大批量从数据库中获取，这是需要避免的，尽量分块或者分批处理，有助于系统的正常稳定的执行。
最后，尽量提高一次请求的执行速度，垃圾回收越早越好。
2.java堆内存泄漏
Java中的内存泄漏是一些对象不再被应用程序使用但垃圾收集无法识别的情况。
因此，这些未使用的对象仍然在Java堆空间中无限期地存在。不停的堆积最终会触发javlang.OutOfMemoryError。
解决方法:
重写equals方法即可：
3.垃圾回收超时内存溢出
当应用程序耗尽所有可用内存时，GC开销限制超过了错误，而GC多次未能清除它，这时便会引发java.lang.OutOfMemoryError。
当JVM花费大量的时间执行GC，而收效甚微，而一旦整个GC的过程超过限制便会触发错误。
解决方法:
要减少对象生命周期，尽量能快速的进行垃圾回收。
4.Metaspace内存溢出
元空间的溢出，系统会抛出java.lang.OutOfMemoryError: Metaspace。
出现这个异常的问题的原因是系统的代码非常多或引用的第三方包非常多或者通过动态代码生成类加载等方法，导致元空间的内存占用很大。
解决方法:
默认情况下，元空间的大小仅受本地内存限制。但是为了整机的性能，尽量还是要对该项进行设置，以免造成整机的服务停机。
5.直接内存内存溢出
在使用ByteBuffer中的allocateDirect()的时候会用到，很多javaNIO(像netty)的框架中被封装为其他的方法，
出现该问题时会抛出java.lang.OutOfMemoryError: Direct buffer memory异常。
如果你在直接或间接使用了ByteBuffer中的allocateDirect方法的时候，而不做clear的时候就会出现类似的问题。
解决办法:
如果经常有类似的操作，可以考虑设置参数：-XX:MaxDirectMemorySize，并及时clear内存。
6.栈内存溢出
当一个线程执行一个Java方法时，JVM将创建一个新的栈帧并且把它push到栈顶。
此时新的栈帧就变成了当前栈帧，方法执行时，使用栈帧来存储参数、局部变量、中间指令以及其他数据。
当一个方法递归调用自己时，新的方法所产生的数据(也可以理解为新的栈帧)将会被push到栈顶，方法每次调用自己时，
会拷贝一份当前方法的数据并push到栈中。因此，递归的每层调用都需要创建一个新的栈帧。这样的结果是，
栈中越来越多的内存将随着递归调用而被消耗，如果递归调用自己一百万次，那么将会产生一百万个栈帧。这样就会造成栈的内存溢出。
解决办法:
如果程序中确实有递归调用，出现栈溢出时，可以调高-Xss大小，就可以解决栈内存溢出的问题了。
递归调用防止形成死循环，否则就会出现栈内存溢出。
7.创建本地线程内存溢出
线程基本只占用heap以外的内存区域，也就是这个错误说明除了heap以外的区域，无法为线程分配一块内存区域了，
这个要么是内存本身就不够，要么heap的空间设置得太大了，导致了剩余的内存已经不多了，而由于线程本身要占用内存，所以就不够用了。
解决方法:
首先检查操作系统是否有线程数的限制，使用shell也无法创建线程，如果是这个问题就需要调整系统的最大可支持的文件数。
日常开发中尽量保证线程最大数的可控制的，不要随意使用线程池。不能无限制的增长下去。
8.超出交换区内存溢出
在Java应用程序启动过程中，可以通过-Xmx和其他类似的启动参数限制指定的所需的内存。
而当JVM所请求的总内存大于可用物理内存的情况下，操作系统开始将内容从内存转换为硬盘。
一般来说JVM会抛出Out of swap space错误，代表应用程序向JVM native heap请求分配内存失败并且native heap也即将耗尽时，
错误消息中包含分配失败的大小（以字节为单位）和请求失败的原因。
解决办法:
增加系统交换区的大小，我个人认为，如果使用了交换区，性能会大大降低，不建议采用这种方式，
生产环境尽量避免最大内存超过系统的物理内存。其次，去掉系统交换区，只使用系统的内存，保证应用的性能。
9.数组超限内存溢出
有的时候会碰到这种内存溢出的描述Requested array size exceeds VM limit，
一般来说java对应用程序所能分配数组最大大小是有限制的，只不过不同的平台限制有所不同，
但通常在1到21亿个元素之间。当Requested array size exceeds VM limit错误出现时，
意味着应用程序试图分配大于Java虚拟机可以支持的数组。JVM在为数组分配内存之前，
会执行特定平台的检查：分配的数据结构是否在此平台是可寻址的。
解决方法:
因此数组长度要在平台允许的长度范围之内。不过这个错误一般少见的，主要是由于Java数组的索引是int类型。
Java中的最大正整数为2 ^ 31 - 1 = 2,147,483,647。 并且平台特定的限制可以非常接近这个数字，
例如：我的环境上(64位macOS，运行Jdk1.8)可以初始化数组的长度高达2,147,483,645（Integer.MAX_VALUE-2）。
若是在将数组的长度再增加1达到nteger.MAX_VALUE-1会出现的OutOfMemoryError。
10.系统杀死进程内存溢出
在描述该问题之前，先熟悉一点操作系统的知识：操作系统是建立在进程的概念之上，这些进程在内核中作业，
其中有一个非常特殊的进程，称为“内存杀手（Out of memory killer）”。当内核检测到系统内存不足时，
OOM killer被激活，检查当前谁占用内存最多然后将该进程杀掉。
一般Out of memory:Kill process or sacrifice child错会在当可用虚拟虚拟内存(包括交换空间)消耗到让整个操作系统面临风险时，会被触发。
在这种情况下，OOM Killer会选择“流氓进程”并杀死它。
解决方法:
虽然增加交换空间的方式可以缓解Java heap space异常，还是建议最好的方案就是升级系统内存，
让java应用有足够的内存可用，就不会出现这种问题。