java.lang.OutOfMemoryError: GC overhead limit exceeded问题分析及解决

Posted 2023-04-03 阿春一Jason

一、错误重现

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 cause

java.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性能社区

Day704.Tomcat内存溢出的原因分析及调优 -深入拆解 Tomcat & Jetty

Tomcat内存溢出的原因分析及调优

Hi，我是阿昌。今天学习记录的是关于Tomcat内存溢出的原因分析及调优。

作为 Java 程序员，我们几乎都会碰到 java.lang.OutOfMemoryError 异常，但是你知道有哪些原因可能导致 JVM 抛出 OutOfMemoryError 异常吗？

JVM 在抛出 java.lang.OutOfMemoryError 时，除了会打印出一行描述信息，还会打印堆栈跟踪，因此我们可以通过这些信息来找到导致异常的原因。

在寻找原因前，我们先来看看有哪些因素会导致 OutOfMemoryError，其中内存泄漏是导致 OutOfMemoryError 的一个比较常见的原因

一、内存溢出场景及方案

1、java.lang.OutOfMemoryError: Java heap space

JVM 无法在堆中分配对象时，会抛出这个异常，导致这个异常的原因可能有三种：

1. 内存泄漏。Java 应用程序一直持有 Java 对象的引用，导致对象无法被 GC 回收，比如对象池和内存池中的对象无法被 GC 回收。
2. 配置问题。有可能是我们通过 JVM 参数指定的堆大小（或者未指定的默认大小），对于应用程序来说是不够的。解决办法是通过 JVM 参数加大堆的大小。
3. finalize 方法的过度使用。如果我们想在 Java 类实例被 GC 之前执行一些逻辑，比如清理对象持有的资源，可以在 Java 类中定义 finalize 方法，这样 JVM GC 不会立即回收这些对象实例，而是将对象实例添加到一个叫“java.lang.ref.Finalizer.ReferenceQueue”的队列中，执行对象的 finalize 方法，之后才会回收这些对象。Finalizer 线程会和主线程竞争 CPU 资源，但由于优先级低，所以处理速度跟不上主线程创建对象的速度，因此 ReferenceQueue 队列中的对象就越来越多，最终会抛出 OutOfMemoryError。解决办法是尽量不要给 Java 类定义 finalize 方法。

2、java.lang.OutOfMemoryError: GC overhead limit exceeded

出现这种 OutOfMemoryError 的原因是，垃圾收集器一直在运行，但是 GC 效率很低，比如 Java 进程花费超过 98％的 CPU 时间来进行一次 GC，但是回收的内存少于 2％的 JVM 堆，并且连续 5 次 GC 都是这种情况，就会抛出 OutOfMemoryError。解决办法是查看 GC 日志或者生成 Heap Dump，确认一下是不是内存泄漏，如果不是内存泄漏可以考虑增加 Java 堆的大小。

当然你还可以通过参数配置来告诉 JVM 无论如何也不要抛出这个异常，方法是配置-XX:-UseGCOverheadLimit，但是我并不推荐这么做，因为这只是延迟了 OutOfMemoryError 的出现。

3、java.lang.OutOfMemoryError: Requested array size exceeds VM limit

抛出这种异常的原因是“请求的数组大小超过 JVM 限制”，应用程序尝试分配一个超大的数组。

比如应用程序尝试分配 512MB 的数组，但最大堆大小为 256MB，则将抛出 OutOfMemoryError，并且请求的数组大小超过 VM 限制。

通常这也是一个配置问题（JVM 堆太小），或者是应用程序的一个 Bug，比如程序错误地计算了数组的大小，导致尝试创建一个大小为 1GB 的数组。

4、java.lang.OutOfMemoryError: MetaSpace

如果 JVM 的元空间用尽，则会抛出这个异常。我们知道 JVM 元空间的内存在本地内存中分配，但是它的大小受参数 MaxMetaSpaceSize 的限制。当元空间大小超过 MaxMetaSpaceSize 时，JVM 将抛出带有 MetaSpace 字样的 OutOfMemoryError。

解决办法是加大 MaxMetaSpaceSize 参数的值。

5、java.lang.OutOfMemoryError: Request size bytes for reason. Out of swap space

当本地堆内存分配失败或者本地内存快要耗尽时，Java HotSpot VM 代码会抛出这个异常，VM 会触发“致命错误处理机制”，它会生成“致命错误”日志文件，其中包含崩溃时线程、进程和操作系统的有用信息。

如果碰到此类型的 OutOfMemoryError，你需要根据 JVM 抛出的错误信息来进行诊断；

或者使用操作系统提供的 DTrace 工具来跟踪系统调用，看看是什么样的程序代码在不断地分配本地内存。

6、java.lang.OutOfMemoryError: Unable to create native threads

1. Java 程序向 JVM 请求创建一个新的 Java 线程。
2. JVM 本地代码（Native Code）代理该请求，通过调用操作系统 API 去创建一个操作系统级别的线程 Native Thread。
3. 操作系统尝试创建一个新的 Native Thread，需要同时分配一些内存给该线程，每一个 Native Thread 都有一个线程栈，线程栈的大小由 JVM 参数-Xss决定。
4. 由于各种原因，操作系统创建新的线程可能会失败，下面会详细谈到。
5. JVM 抛出“java.lang.OutOfMemoryError: Unable to create new native thread”错误。

因此关键在于第四步线程创建失败，JVM 就会抛出 OutOfMemoryError，那具体有哪些因素会导致线程创建失败呢？

内存大小限制：我前面提到，Java 创建一个线程需要消耗一定的栈空间，并通过-Xss参数指定。请你注意的是栈空间如果过小，可能会导致 StackOverflowError，尤其是在递归调用的情况下；但是栈空间过大会占用过多内存，而对于一个 32 位 Java 应用来说，用户进程空间是 4GB，内核占用 1GB，那么用户空间就剩下 3GB，因此它能创建的线程数大致可以通过这个公式算出来：

Max memory（3GB） = [-Xmx] + [-XX:MaxMetaSpaceSize] + number_of_threads * [-Xss]

不过对于 64 位的应用，由于虚拟进程空间近乎无限大，因此不会因为线程栈过大而耗尽虚拟地址空间。

但是注意，64 位的 Java 进程能分配的最大内存数仍然受物理内存大小的限制。

ulimit 限制，在 Linux 下执行ulimit -a，你会看到 ulimit 对各种资源的限制。

其中的“max user processes”就是一个进程能创建的最大线程数，我们可以修改这个参数：

参数sys.kernel.threads-max限制。这个参数限制操作系统全局的线程数，通过下面的命令可以查看它的值。

这表明当前系统能创建的总的线程是 63752。当然我们调整这个参数，具体办法是：

在/etc/sysctl.conf配置文件中，加入sys.kernel.threads-max = 999999。

参数sys.kernel.pid_max限制，这个参数表示系统全局的 PID 号数值的限制，每一个线程都有 ID，ID 的值超过这个数，线程就会创建失败。跟sys.kernel.threads-max参数一样，我们也可以将sys.kernel.pid_max调大，方法是在/etc/sysctl.conf配置文件中，加入sys.kernel.pid_max = 999999。

对于线程创建失败的 OutOfMemoryError，除了调整各种参数，我们还需要从程序本身找找原因，看看是否真的需要这么多线程，有可能是程序的 Bug 导致创建过多的线程。

二、内存泄漏定位实战

我们先创建一个 Web 应用，不断地 new 新对象放到一个 List 中，来模拟 Web 应用中的内存泄漏。然后通过各种工具来观察 GC 的行为，最后通过生成 Heap Dump 来找到泄漏点。

内存泄漏模拟程序比较简单，创建一个 Spring Boot 应用，定义如下所示的类：

import org.springframework.scheduling.annotation.Scheduled;
import org.springframework.stereotype.Component;

import java.util.LinkedList;
import java.util.List;

@Component
public class MemLeaker 

    private List<Object> objs = new LinkedList<>();

    @Scheduled(fixedRate = 1000)
    public void run() 

        for (int i = 0; i < 50000; i++) 
            objs.add(new Object());
        
    

这个程序做的事情就是每隔 1 秒向一个 List 中添加 50000 个对象。

接下来运行并通过工具观察它的 GC 行为：

运行程序并打开 verbosegc，将 GC 的日志输出到 gc.log 文件中。

java -verbose:gc -Xloggc:gc.log -XX:+PrintGCDetails -jar mem-0.0.1-SNAPSHOT.jar

使用jstat命令观察 GC 的过程：

jstat -gc 94223 2000 1000

94223 是程序的进程 ID，2000 表示每隔 2 秒执行一次，1000 表示持续执行 1000 次。下面是命令的输出：

其中每一列的含义是：

• S0C：第一个 Survivor 区总的大小；
• S1C：第二个 Survivor 区总的大小；
• S0U：第一个 Survivor 区已使用内存的大小；
• S1U：第二个 Survivor 区已使用内存的大小。

后面的列相信从名字你也能猜出是什么意思了，其中 E 代表 Eden，O 代表 Old，M 代表 Metadata；YGC 表示 Minor GC 的总时间，YGCT 表示 Minor GC 的次数；FGC 表示 Full GC。通过这个工具，你能大概看到各个内存区域的大小、已经 GC 的次数和所花的时间。verbosegc 参数对程序的影响比较小，因此很适合在生产环境现场使用。

通过 GCViewer 工具查看 GC 日志，用 GCViewer 打开第一步产生的 gc.log，会看到这样的图：

图中红色的线表示年老代占用的内存，你会看到它一直在增加，而黑色的竖线表示一次 Full GC。

你可以看到后期 JVM 在频繁地 Full GC，但是年老代的内存并没有降下来，这是典型的内存泄漏的特征。

除了内存泄漏，我们还可以通过 GCViewer 来观察 Minor GC 和 Full GC 的频次，已及每次的内存回收量。

为了找到内存泄漏点，我们通过 jmap 工具生成 Heap Dump：

jmap -dump:live,format=b,file=94223.bin 94223

用 Eclipse Memory Analyzer 打开 Dump 文件，通过内存泄漏分析，得到这样一个分析报告：

从报告中可以看到，JVM 内存中有一个长度为 4000 万的 List，至此我们也就找到了泄漏点。

---