1. JVM 对象分配

前面两篇文章介绍了Metaspace区和Java虚拟机栈的内存溢出的分析及解决方案；一般来说，只要配置了合理的jvm参数和代码上注意一些，是不太容易发生这两块区域的内存溢出的。

真正最容易发生OOM的，是在 Java堆 中，也就是由于 平常系统中创建出来的对象实在太多了，最终导致了系统的OOM；

前面也介绍过了jvm运行时在堆中创建对象和回收的流程，在这里就只再做一个简略的对象分配回顾：

1、 系统运行时会一直不停地创建对象，这些对象会先分配到Eden区；
2、 Eden区满了之后，就会触发YGC，然后存活对象进入Survivor区；
3、 如果存活对象太多，Survivor区放不下的时候，就会通过分配担保进入到老年代中；
4、 如果每次都有对象进入到老年代，也就会很快填满老年代；在老年代满了的时候，触发FGC；
5、 如果老年代FGC之后，存活的对象还是很多，并且新生代继续往老年代进入对象；
6、 在不能放下继续进入老年代的对象的时候，导致发生堆空间的OOM；

2. 什么情况会发生 Heap OOM

根据上面的对象分配流程，发生堆内存溢出的原因，总结下来就是：

• 在新生代中的对象经过YGC之后大部分都是存活的，然后进入老年代经历FGC之后，仍然大部分都是存活的；所以老年代不能再继续放入更多对象，就导致了OOM。

针对这个原因，一般来说发生堆内存溢出就主要有两种场景：

1、 系统承载高并发请求：；

• 因为请求量很大，就会创建很多的对象；

• 因为请求量很大，系统处理就会变慢，导致GC的时候很多对象都是存活的；

• 所以在FGC之后大量对象存活，并且继续放入，引发OOM； 2、 系统存在内存泄漏问题：；

• 存在内存泄漏，对于大量对象没有及时清除引用，不能被GC掉；

• 这些对象一直占据老年代空间，如果有新生代对象进入老年代，放不下了就会引发OOM；

这是两种主要场景，其他当然还有很多比如JVM内存分配不合理什么的，但是这些并不一定会导致堆内存溢出，可能更多的是导致频繁Full GC。

3. 模拟 Heap OOM

/**
 *
 * 堆内存溢出
 *
 * jvm options：
 *  -Xms100m -Xmx100m -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:+PrintGCDetails -Xloggc:log/heap-oom.log
 *  -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=hprof/heap-oom
 */
public class HeapOomDemo {
   
     

	public static void main(String[] args) {
   
     
		int count = 0;
		List<byte[]> list = new ArrayList<>();

		while (true) {
   
     
			list.add(new byte[1 * 1024 * 1024]);
			System.out.println("当前创建了 " + (++count) + "M 的对象");
		}
	}
}

这段代码也很简单，就是在一个while死循环里面不停地创建对象，并且使用一个list来存储对象，也就是说这些对象全部存在引用，不能被GC掉。

JVM参数为 -Xms100m -Xmx100m，没有指定新生代大小，也就是按照默认比例分配，新生代大概30M左右，老年代大概60多M左右。

简要分析一下代码执行流程：

1、 一直创建对象放在Eden区，在放入了快要满30M的时候（假设28M），发生YGC；这28M的对象不能被回收，全部进入老年代（老年代28M）；
2、 YGC之后，继续放入Eden区，再次到28M的时候，发生YGC；继续放入老年代（老年代56M）；
3、 继续执行，继续放入Eden区，再次到28M的时候，想要发生YGC，但是此时老年代已经有56M了，距离老年代空间限度很小了，所以不能直接发生YGC；
4、 就需要先执行FGC清除老年代的空间，但是这56M的对象，都被引用持有，在老年代也不能被GC掉，所以老年代依然占据56M空间；
5、 此时新生代的对象还得进入老年代，但是老年代装不下了；没有办法，直接抛出OOM了；

再来看下GC日志：

从GC日志的数据呈现来看，我们上面的分析大致正确；

再来看下代码执行结果：

在创建了95M对象的时候，发生了 OutOfMemoryError: Java heap space；

4. Heap OOM 的定位及解决

发生OOM之后，往往系统会很快崩溃掉，对于所有请求都不再响应，这个时候自然要登录到服务器上检查日志文件；
在检查日志的时候，就会看到上图的 OutOfMemoryError: Java heap space提示，自然就知道了系统发生了 堆内存溢出;

并且我们是打开了jvm的dump开关的，所以日志文件中也会显示 dump出了一份名为 java_pidxxxxx.hprof 的内存快照；

有了这个，自然是使用MAT进行分析了：

1、 打开MAT，直接查看Actions->DominatorTree:；

可以看到，这里有95个大小为1M的byte[]数组对象，他们一共占用了99%左右的内存空间； 2、 继续查看Reports->LeakSuspects：；

也能看出这里的95M对象； 3、 继续点击Seestacktrace进行查看：；

这里就看到了是 HeapOomDemo.java 类的第 21行处代码最终引发堆内存溢出的； 4、 再回到代码检查：；
list.add(new byte[1 * 1024 * 1024]);
也就是这行一直创建1M的byte[]数组对象的代码导致的…

通过MAT工具对于dump出来的内存快照进行分析，找到占用内存最多的对象，再定位到引发堆内存溢出的具体类和方法；

再结合代码进行分析，自然就能知道发生这次OOM的原因和解决办法了。