内存溢出(Out Of Memory，简称OOM)是指应用系统中存在无法回收的内存或使用的内存过多，最终使得程序运行要用到的内存大于能提供的最大内存。此时程序就运行不了，系统会提示内存溢出，有时候会自动关闭软件，重启电脑或者软件后释放掉一部分内存又可以正常运行该软件，而由系统配置、数据流、用户代码等原因而导致的内存溢出错误，即使用户重新执行任务依然无法避免。
溢出原因内存溢出就是内存不够，引起内存溢出的原因有很多种，常见的有以下几种：
1、内存中加载的数据量过于庞大，如一次从数据库取出过多数据；
2、集合类中有对对象的引用，使用完后未清空，使得JVM不能回收；
3、代码中存在死循环或循环产生过多重复的对象实体；
4、使用的第三方软件中的BUG；
5、启动参数内存值设定的过小；
当然实际情况中内存溢出的原因就太多了。下面我们就对这些原因分类一下：
以上的图是基于java7来叙述的，从上面这张图我们能够得到如下信息：java虚拟机把内存分为5个模块。
（1）程序计数器：程序计数器是线程私有的，主要的作用是通过改变这个计数器的值来选取下一条需要执行的字节码指令。既然每个线程都有一个，那么这些线程的计数器是互不影响的。也不会抛出任何异常。
（2）虚拟机栈和本地方法栈：虚拟机栈描述的是java方法执行的内存模型，每个方法在执行的时候都会创建一个栈帧用于存储局部变量表、操作数栈、动态连接、方法出口等信息。本地方法栈与虚拟机栈的区别是，虚拟机栈为虚拟机执行java方法服务，而本地方法栈则为虚拟机提供native方法服务。
在单线程的操作中，无论是由于栈帧太大，还是虚拟机栈空间太小，当栈空间无法分配时，虚拟机抛出的都是StackOverflowError异常，而不会得到OutOfMemoryError异常。而在多线程环境下，则会抛出OutOfMemoryError异常。
（3）java堆和方法区：java堆区主要存放对象实例和数组等，方法区保存类信息、常量、静态变量等等。运行时常量池也是方法区的一部分。这两块区域是线程共享的区域，只会抛出OutOfMemoryError。
内存溢出实例1、堆溢出
既然堆是存放实例对象的，那我们就无限创建实例对象。这样堆区迟早会满。
因为我提前设置了堆区内存，所以无限创建就会抛出异常。
2、虚拟机栈和本地方法栈溢出
Java虚拟机规范中描述了两种异常：
第一种我们只需要使用方法递归调用即可模拟：
第二种也可以递归调用模拟,，但是使用的是类直接调用。
3、方法区和运行时常量池溢出
4、本机直接内存溢出
DirectMemory容量可通过-XX: MaxDirectMemorySize指定，如果不指定，则默认与Java堆最大值 (-Xmx指定)一样。
5、定时任务导致溢出
报错定位：com.ibatis.sqlmap.engine.mapping.statement.RowHandlerCallback
分析：有时候我们需要一次性处理大量的数据几万甚至上百万，如果一次性加载到内存很可能导致OOM。如果使用Ibatis作为ORM映射工具，我们会用到RowHandler这个接口来处理。Ibatis中大致的实现思路是通过RowHandlerCallback封装一个RowHander对象从而在迭代都去每条记录时回调handleRow方法从而避免一次性全部加载到内存。不过需要注意的一点是：如果你的handleRow方法处理逻辑比较耗时这种方式处理的数据量很大的话可能大幅增加jdbc连接占用的时间,可能导致连接池吃紧的状况出现。
原因：有一个定时任务会在特定的时间大批量更新表数据(平均每天一万条需要执行20分钟以上的更新操作最长一次1小时55分钟)的同时前端对同一张表频繁查询导致了数据库压力大，查询结果堆积直到内存被撑爆。
排查其实最主要的就是检查代码，而且内存溢出往往都是代码的问题。当然一下几点都是需要注意的：
（1）内存中加载的数据量过于庞大，如一次从数据库取出过多数据；
（2）集合类中有对对象的引用，使用完后未清空，使得JVM不能回收；
（3）代码中存在死循环或循环产生过多重复的对象实体；
（4）使用的第三方软件中的BUG；
（5）启动参数内存值设定的过小；
最后就是解决了。
第一步，修改JVM启动参数，直接增加内存。
第二步，检查错误日志
第三步，对代码进行走查和分析，找出可能发生内存溢出的位置。
一般情况下代码出错的概率会比较大一些，当然了不同的场景不同错误总是复杂多样的。