上午系统崩溃（OOM），下午就喜提大礼包

置顶

精

活动

科叼 2025-08-01 10:22:41 来自江苏板块：开源硬件平台互动量：47

前言

不好啦❗ 天塌了❗ 系统崩了❗

快看啊，程序outOfMemoryError了🙈

我的心里活动：“哈哈哈😀哈哈哈😀终于给我碰上了，这个问题可很少发生啊，又积累一个问题。虽然我昨天发了版本，但是作为公司技术最好，长得最帅的我，代码肯定不出现这个问题。”

不想看废话的直接看【解决过程和方案】吧

排查过程

首先肯定是先看日志，根据日志信息可以看到三个关键信息：

1. 业务代码中调用了远程接口

2. 内存溢出outOfMemoryError

3. Arrays.copyOf(Arrays.java:3332)

猜想❔

得到关键信息后，看了代码之后我就和技术经理做了一个简单的讨论

技术经理：调用远程接口没有设置超时时间，访问人数突然增多，导致请求阻塞。瞬间一万个请求进来，然后一个万的请求就阻塞了，从而导致内存溢出
我的猜想：请求之前没有查询大量的数据，就算请求阻塞也不会占用大量内存，导致outOfMemory. 还有就是Tomcat的线程池也默认200,。就算一万个请求进来，同一时刻也最多处理200个请求，这个200个请求都阻塞的话会造成系统卡死，但是不会出现outOfMemoryError呀
虽然抛出了一个业务代码的错误，但是并不能肯定就是它引发的outOfMemoryError,也可能是其他任务占了太多内存，这个请求只是一根“稻草”

顺便吆喝一句→技术大厂，前后端测试捞人，刚兴趣试试~

解决过程和方案✔

修改启动命令，导出堆信息
定位outOfMemoryError 还得用证据说话呀! 让技术经理在启动命令上加了如下参数-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=./heapdump.hprof 再次出现内存溢出就会将堆信息导出。
分析堆信息，定位大内存对象
因为之前已经装过分析dump文件的工具了，我用的是Intellij Profiler工具
根本问题已经浮出水面了，KbResultSet、List<UnionCustomerCheckLog>这两个对象几乎把内存撑满了，jvm 堆内存最大1024M 这两个就占了700M. 算是定位到问题了吧! 也推翻了技术经理说的调用远程接口大量请求被阻塞的问题。
查找GC回收日志
我们搜索自己的业务包名字就行了，这样就能很快定位关键问题。发现存在service 名称和上面大对象的名称一致UnionCustomerCheckLog

同样的搜索方式在summary栏目搜索，也能匹配上，并且定位到代码方法queryXXPassList()

定位问题代码、分析代码
找到关键代码之后我们就看看代码吧：
select * ？这个写法是开发禁忌哦，加上这个sql 的查询的结果有40W 条了。
看看这个查询有啥用呢❓ 看看伪代码吧：

下面代码就是用代码实现的分组统计........没错就是我们 Android 工程师写的，因为公司去年就不用维护客户端了，安卓写java，ios写前端。

刚好上午给老哥指出问题，下午就被人事约谈，领了大礼包了。

// 查询出需要的所属数据：40w条
List<UnionCustomerCheckLog> xxPassList = unionCustomerCheckLogService.queryXXPassList();

// 分组统计
Map<Integer, List<UnionCustomerCheckLog>> unionMap =
        xxPassList.stream().collect(Collectors.groupingBy(UnionCustomerCheckLog::getSource));
        
for (DictModel dict : modelList) {
    ChartVo vo = new ChartVo();
    vo.setName(dict.getText());
    List<UnionCustomerCheckLog> checkLogList = unionMap.get(Integer.valueOf(dict.getValue()));
    if (Objects.isNull(checkLogList)) {
        vo.setNumber(0L);
    } else {
        // 统计长度
        vo.setNumber((long) checkLogList.size());
    }
    voList.add(pieChartVo);
}

解决问题
既然上面已经分析出问题所在了，就是Android老哥还不太会分组统计，就把数据全部查询到内存中统计。导致outOfMemoryError.
解决方法修改统计，改成SQL分组统计就行了：
程序逻辑也相应的调整就行了。

知识拓展

`OutOfMemoryError` 简单介绍

JVM 在内存不足时会先尝试 Full GC 回收无用对象。如果 GC 后仍无法分配内存，才会抛出 OutOfMemoryError。常见类型有：

堆内存不足：java.lang.OutOfMemoryError: Java heap space。
元空间（方法区）不足：java.lang.OutOfMemoryError: Metaspace。
栈内存溢出：java.lang.StackOverflowError（本质是栈内存的 OOM）。
直接内存不足：java.lang.OutOfMemoryError: Direct buffer memory。

垃圾回收（GC）超时：java.lang.OutOfMemoryError: GC overhead limit exceededGC 时间占比过高：JVM 在连续多次 GC 中，超过 98% 的时间用于垃圾回收。

回收效果极差：每次 GC 后，堆内存释放量不足 2% 。

持续触发：上述情况持续发生，导致 JVM 判定应用已无法通过 GC 恢复可用内存

`OutOfMemoryError` 系统会直接挂掉么？

不一定，主要看以下几个因素

1. 取决于 OOM 的类型和影响范围

堆内存 OOM：
如果未捕获异常，仅当前线程终止，其他线程可能正常处理请求。但堆内存不足可能导致后续请求继续触发 OOM，最终系统逐渐不可用。
元空间 OOM（如类加载失败）：
可能导致 JVM 无法加载新类，影响功能完整性。
栈溢出（StackOverflowError） ：
通常仅终止当前线程，但如果是主线程崩溃，整个进程会退出。

2. JVM 配置的影响

-XX:+CrashOnOutOfMemoryError：强制 JVM 在 OOM 时立即崩溃，生成核心转储文件，系统不可用。
-XX:+HeapDumpOnOutOfMemoryError：仅生成堆转储文件，JVM 进程可能继续运行（但状态可能不稳定）。

3. 代码设计

如果捕获了 OutOfMemoryError 并尝试释放资源（如关闭连接、清理缓存），可能恢复部分功能。
但 OOM 通常是系统性问题的表现，即使捕获异常，应用状态可能已不可靠。

总结

由于工程师分组统计方式错误的实现，本来在数据库统计就行了，然而Android老哥却全部查询出来，然后再程序统计导致的内存溢出。

本篇文章分享了我去排查outOfMermoryError问题的过程，希望能帮到你，感谢一键三连🚀🚀🚀

有趣的是，上午定位到问题，并确认是Android老哥写的，下午老哥就被约谈了，喜提大礼包。最近公司大裁员呀，已经裁了三分之一了，老哥们祝福我吧🧡🧡🧡

——转载自：提前退休的java猿

开源硬件平台

还没有评论，抢个沙发！

上午系统崩溃（OOM），下午就喜提大礼包 置顶 精 活动

前言