一、错误重现

2022-12-29 10:12:07.210 ERROR 73511 --- [NIO-8001-exec-6] o.a.c.c.C.[.[.[/].[dispatcherServlet]    : Servlet.service() for servlet [dispatcherServlet] in context with path [] threw exception [Handler dispatch failed; nested exception is java.lang.OutOfMemoryError: GC overhead limit exceeded] with root causejava.lang.OutOfMemoryError: GC overhead limit exceeded

出现该问题的原因：当GC为释放很小空间占用大量时间时会抛出此异常，即（Sun 官方对此的定义，超过98%的时间用来做GC并且回收了不到2%的堆内存时会抛出此异常）。一般是因为堆太小，导致异常的原因：没有足够的内存。

对于该项目我的启动命令如下：堆内存空间开辟的是256m

nohup java -Xms256m -Xmx256m -Dspring.profiles.active=test -jar ...

在数据量没有巨量增加的时候该对内存空间是足够的，因为我们的文件基本都在1m以内，所以开辟的内存空间也足够，但是后来由于算法业务的变化，数据量直接达到了50m多，因此就出现了上面的OOM的情况，在一次请求的情况下YGC就达到了81次，FGC达到了51次。具体信息如下：

二、问题分析

其实出现OOM的情况很多，今天主要就我这种情况进行一个简单的分析，该错误信息：

java.lang.OutOfMemoryError: GC overhead limit exceeded

当然出现该问题的主要原因在于：项目启动的时候堆内存空间分的不够，不过我们也能够从自身的代码做一些优化，比如说：可以让处理数据的过程变得更加简单一下，不要有过多的内存开销情况，这种情况也是要对JVM启动参数进行重新调整；另一个方面我们可以直接从JVM分配堆内存的角度进行优化，当然需要对我们的业务了解后，将项目做一个业务模型的提炼，然后分析该模型的内存开销情况，根据分析的内存开销情况对JVM内存做出预判。

三、问题解决

我们在清楚了问题的情况下，接下来主要分享解决问题的过程，其实这里很多人可能会问，我们对JVM的内存开辟主要依据是什么？到底这个内存开辟多少合适？

我个人认为这个问题的关键在于我们对系统主要业务的了解，然后对主要业务流程建立业务模型，再对业务模型的请求数据量做大概的估算，即便是具有高并发的系统也是如此方法计算。下面就拿我们的系统来打比方：我们的系统模型中内存开销最多的情况在于用户数据的导入+算法计算后的数据量，这样一来我们就可以计算出该模型中一次请求大概的内存开销。如果有高并发，在计算出每秒钟有多少次这样的请求，这样就很容易计算出JVM启动的内存大概开辟多少合适。当我调整后启动命令如下：

nohup java -Xms1024m -Xmx1024m -Dspring.profiles.active=test -jar ...

我这个系统demo计算的依据在于：

1、该系统中消耗内存最大的地方是：用户导入数据+算法计算后数据的处理；

2、该系统的算法计算后数据大概在50m多，这里也就是说一个请求过来我数据量占用的内存就要达到50m；

3、该次请求中其它内存消耗估算在50m，因为用户导入数据也非常耗费内存；

4、当然还有很多的增删改查操作：估算在100m；

5、最后在我们计算出来的主要开销情况下扩大5到10倍。

所以我就单台服务器开辟JVM内存空间在1024m，在正常情况下还是没有问题的。

这里非常明显能够看到YGC进行了41次，FGC进行了0次：

四、总结

其实平时我们学习再多的理论知识，不如一次生产实践中遇到一次问题带来的收获多。当然这里分享的如有错误还望指出，只有这样才能不断的进步。

参考文档：Java OOM 基础篇：常见的OutOfMemoryError 场景二 : GC overhead limit exceeded 问题详解 | HeapDump性能社区

来源地址：https://blog.csdn.net/whc888666/article/details/128496598