项目报 OutOfMemoryError 、GC overhead limit exceeded 问题排查以及解决思路实战

项目报 OutOfMemoryError、GC overhead limit exceeded 问题排查以及解决思路实战

前言：
问题现象描述：
1，生产环境有个定时任务，没有初始化告警数据【告警数据量为1000多个】
2，其他定时任务执行正常
3，查询日志到定时任务执行之前有日志打印
4，手动触发补偿告警定时任务接口报OutOfMemoryError GC overhead limit exceeded，也会报

1、现象问题排查

1.1 程序是否触发判断

1，首先定时任务之前可以正常初始化告警指标数据，说明程序可以正常执行，不会存在问题【初次判断】

1.2 JVM内存大小查看

2，会不会是内存不够用导致的结果，使用arthas工具查看内存使用情况
输入memory 返回如下信息

1，其中堆空间eden_space 区内存：总共462M，已使用310M
2，还剩下大概 150M左右【大概够用，只是猜想】

1.3 手动触发定时任务查看内存使用情况

1，现象是eden_space 很快达到99%，并且报GC overhead limit exceeded

1.4 查看定时任务代码逻辑，发现创建大量对象大概1000多个对象【在一瞬间】，代码大概如下。

1，为啥是1000多个对象，是因为有1000多个告警，要在凌晨触发定时任务生成告警指标数据
2，告警的数据，是kafka接收的，kafka监听到数据实时拉取数据，批量保存到数据库
3，告警有4大类，每个类有12个类别

未优化前逻辑

private final int batchSize = 500;
public void initKafkaAlarmInventoryTask() {
        // 待批量保存清单数据
        List<TaskAlarmInventoryEntity> batchInsertTaskInventoryList = new ArrayList<>();
        // 1.获取需要初始化的告警数据 
        // TODO: 从数据库查询 
        List<InitAlarmTaskInventoryEntity> initTaskInventoryEntities = .....
       //  initInspectionSystemMap key:为告警的类型【12大类型】 v:每个类型下面的指标集合
       initInspectionSystemMap.forEach((k, v) -> {
       		// 对每个指标进行遍历
            v.forEach(x -> {
                	// 相关业务逻辑 如果当前的告警数据已经消费到，就跳过，否则就保存消息
                	batchInsertTaskInventoryList.add(....);
                }
            });

        });
        if (CollectionUtils.isNotEmpty(batchInsertTaskInventoryList)) {
            for (int i = 0; i < batchInsertTaskInventoryList.size(); i += batchSize) {
                int endIndex = Math.min(i + batchSize, batchInsertTaskInventoryList.size());
                // TODO：保存到数据库
            }
        }
    }
    }

优化后：

private final int batchSize = 500;
public void initKafkaAlarmInventoryTask() {
        // 待批量保存清单数据
        List<TaskAlarmInventoryEntity> batchInsertTaskInventoryList = new ArrayList<>();
        // 1.获取需要初始化的告警数据 
        // TODO: 从数据库查询 
        List<InitAlarmTaskInventoryEntity> initTaskInventoryEntities = .....
       //  initInspectionSystemMap key:为告警的类型【12大类型】 v:每个类型下面的指标集合
       initInspectionSystemMap.forEach((k, v) -> {
       		// 对每个指标进行遍历
            v.forEach(x -> {
                	// 相关业务逻辑 如果当前的告警数据已经消费到，就跳过，否则就保存消息
                	batchInsertTaskInventoryList.add(....);
                }
            });
        if (CollectionUtils.isNotEmpty(batchInsertTaskInventoryList)) {
            for (int i = 0; i < batchInsertTaskInventoryList.size(); i += batchSize) {
                int endIndex = Math.min(i + batchSize, batchInsertTaskInventoryList.size());
                // TODO：保存到数据库
            }
        }
    }
        });
    }

4，可能是一次性初始化1000多个对象把堆内存使用完导致的这个问题，优化成根据告警指标类型分类 分成几百个类初始化，打包重新调用后，还是同样问题报错【本地执行没有问题】

1.5 使用arthas 跟踪接口执行情况

使用trace命令查看每个方法的调用时间，以及调用情况

[arthas@13362]$ trace com.xxx.xx.xx.kafka.KafkaAlarmReportConsumerClient initKafkaAlarmInventoryTask

命令大概意思是：
arthas 允许你监控指定类的方法执行过程，记录每个方法执行的时间、调用链等详细信息。
com.xxx.xx.xx.kafka.KafkaAlarmReportConsumerClient：这是目标类的完全限定名，表示 KafkaAlarmReportConsumerClient类。
initKafkaAlarmInventoryTask：这是你要追踪的方法名。Arthas 将监控该方法的执行，并返回详细的执行信息。

返回如下消息：

`---[18808.94593ms] com.xx.xxx.platform.kafka.KafkaAlarmReportConsumerClient $$EnhancerBySpringCGLIB$\$4ead41fc:initKafkaAlarmInventoryTask() [throws Exception]
    +---[100.00% 18808.534277ms ] org.springframework.cglib.proxy.MethodInterceptor:intercept() [throws Exception]
    |   `---[99.93% 18794.767357ms ] com.xx.xxx.xx.kafka.KafkaReportConsumerClient:initKafkaAlarmTask() [throws Exception]
    |       +---[0.00% 0.032337ms ] com.xx.xx.platform.entity.dao.TaskInventoryDao:builder() #826
    |       +---[0.00% 0.220948ms ] com.xxx.major.common.utils.DateUtils:getStartDate() #826
    |       +---[0.00% 0.014243ms ] com.xx.xx.platform.xxx.xx.TaskInventoryDao$TaskInventoryDaoBuilder:synStartDate() #826
    |       +---[0.00% 0.224577ms ] com.xxx.xxx.common.utils.DateUtils:getEndDate() #826
    |       +---[0.00% 0.010579ms ] com.xxx.major.xxx.entity.xxx.TaskInventoryDao$TaskInventoryDaoBuilder:synEndDate() #826
    |       +---[0.00% 0.009368ms ] com.xx.major.xxx.entity.xxx.TaskInventoryDao$TaskInventoryDaoBuilder:build() #826
    |       +---[0.21% 38.643543ms ] com.xxx.major.xxx.service.TaskInventoryService:queryTaskInventoryByTaskInventoryDao() #825
    |       +---[0.60% 112.059449ms ] com.xxx.major.platform.service.InitTaskInventoryService:queryAllInitTaskInventory() #836
    |       +---[0.00% 0.286756ms ] com.xxx.major.common.utils.DateUtils:getEndDate() #842
    |       +---[0.17% 32.261925ms ] com.xxxx.major.platform.service.TaskInventoryService:queryTaskInventoryByParam() #842
    `---throw:java.lang.OutOfMemoryError #-1 [GC overhead limit exceeded]

返回的大概意思是：

2.3.1. 方法调用路径:
com.xxx.major.platform.kafka.KafkaAlarmReportConsumerClient KaTeX parse error: Can't use function '$' in math mode at position 22: …erBySpringCGLIB$̲\$4ead41fc:init…EnhancerBySpringCGLIB$$4ead41fc）是由 Spring 的 CGLIB 动态代理生成的类，initKafkaAlarmTask 是该方法。它的执行时间是 18808.94593ms（约 18.8 秒）。

org.springframework.cglib.proxy.MethodInterceptor:intercept() [throws Exception]：
这表示 Spring AOP 拦截器的执行，它拦截了对 initKafkaAlarmTask 的调用，并花费了 18808.534277ms。

com.xxx.major.platform.kafka.KafkaReportConsumerClient:initKafkaAlarmTask() [throws Exception]：
这表示实际的业务逻辑方法 initKafkaAlarmTask 被执行，并且占用了 18794.767357ms，几乎占用了整个时间。

2.3.2. 方法调用过程中的内部调用:
接下来是对 initKafkaAlarmTask 方法内部的其他方法的详细追踪：

TaskAlarmInventoryDao.builder()：用时 0.032337ms。
DateUtils.getStartDate()：用时 0.220948ms。
TaskAlarmInventoryDao$TaskAlarmInventoryDao.synStartDate()：用时0.014243ms。DateUtils.getEndDate()：用时0.224577ms。TaskAlarmInventoryDao$TaskAlarmInventoryDao.synEndDate()：用时 0.010579ms。
TaskAlarmInventoryDao$TaskAlarmInventoryDao.build()：用时 0.009368ms。
TaskAlarmInventoryService.queryTaskIAlarmnventoryByTaskInventoryDao()：用时 38.643543ms。
InitTaskAlarmInventoryService.queryAllAlarmInitTaskInventory()：用时 112.059449ms。
TaskAlarmInventoryService.queryTaskAlarmInventoryByParam()：用时 32.261925ms。

简短说，异常信息是：
最后，输出中显示了一个 java.lang.OutOfMemoryError 异常，指示发生了 GC overhead limit exceeded 错误。这表示在执行过程中，JVM 因垃圾回收器（GC）花费了过多的时间，但并未有效释放内存，导致内存溢出异常。

throw:java.lang.OutOfMemoryError #-1 [GC overhead limit exceeded] 表明 JVM 由于 GC 限制，无法回收足够的内存，最终触发了 OutOfMemoryError。

1.6 查看JVM参数配置：

arthas 输入 jvm，返回如下内容 生成环境是1g，测试环境是512M这里只是做个已有JVM参数样例

1，问题一：
永久代和 Metaspace 配置：

由于 Java 8 及以后版本中已经没有永久代（PermGen），而是使用 Metaspace，因此 -XX:PermSize 和 -XX:MaxPermSize 参数已经不再生效。
建议： 移除这些不再有效的参数，使用 Metaspace 相关的参数，如 -XX:MetaspaceSize 和 -XX:MaxMetaspaceSize，例如

-XX:MetaspaceSize=128M
-XX:MaxMetaspaceSize=512M

2，问题二：
当发生 OutOfMemoryError（OOM）错误时，JVM（Java虚拟机）会生成一个堆转储文件（heap dump）。这个文件包含了JVM内存堆的快照，包含了Java对象的详细信息，帮助开发者和运维人员分析和定位内存泄漏或内存不足的原因。分析堆转储文件是解决这类问题的一个重要步骤。

1. 堆转储文件的生成
   当出现 OutOfMemoryError 时，JVM会通过以下方式生成堆转储文件：

使用 -XX:+HeapDumpOnOutOfMemoryError 参数自动在OOM发生时生成堆转储。
堆转储文件通常会保存到指定的文件路径，如：-XX:HeapDumpPath=/path/to/dump.hprof。

查看当前文件夹存在xxx.hprof快照信息

1.7 将堆转储文件copy出来，用jdk自带的 java VisualVm分析

1，双击执行

2，文件 装入 快照信息

3，文件类型选择并装入

4，注意文件类型，是否选错

5，点击异常线程选择，找到问题所在

6，问题定位

找到问题的代码位置

7，根据问题找到的代码位置

8，计算类所占内存的大小

这里可以看到最大的有char[]实例大小和总大小，总实例的个数是740890，总大小是306,889,752单位是B，换成MB为，306,889,752➗1024➗1024≈292.67287445068359375≈293MB，这个跟启动JVM参数设置最大堆内存设置-Xmx512M 和这个相差不大**（-Xmx=512m虽然堆分配是512m,但是JVM会拓展）**

如果没有显示引用下面的数据，记得把这个点开

2、问题跟踪解决

问题一：
1，定时任务触发，会很一次性触发1000多个对象，
解决方案：
拆分成根据告警指标类型进行分开，仍然是批处理，一次性创建的对象最大为500个左右
问题二：
根据上面排查原因点7，发现是kafka消费者拉取数据量为500而且是多线程导致，造成数据量庞大，内存OOM，
解决方案：
1、把多线程去掉，或者最大线程数改为单个，每次拉取500个数据，
2、查看当前服务器内存使用情况
free -h
返回如下，mem的free还剩1.2G，加到当前服务JVM参数即可

并调整-Xms堆的大小 改为512m+1024m

3、遇到的问题

1，arthas 服务器拉取不到，需要外网下载好arthas，copy到服务器
电脑盘创建文件夹执行如下命令即可
参考官网网址：https://arthas.aliyun.com/doc/install-detail.html

-- 下载arthas
curl -O https://arthas.aliyun.com/arthas-boot.jar
-- 执行脚本
java -jar arthas-boot.jar

2，服务器hprof快照信息，导出win环境，可能权限不对，要将hprof快照信息设置成所有人都可执行的权限

-- 修改为所有用户都可以执行
chmod a+rwx java_pid25304.hprof

3，JVM已有参数配置失效，JVM调优参数下一期讲解 待完成…

本次OOM，GC问题做个记录分享给大家，生产项目难免有些没有表达合理CV清楚，欢迎指出来，我这边改好更新后再发上去
喜欢我的文章记得点个在看，或者点赞，持续更新中ing…