上午系统崩溃,下午就喜提大礼包

首页 编程分享 PHP丨JAVA丨OTHER 正文

提前退休的java猿 转载 编程分享 2025-02-22 22:03:24

简介 不好啦❗ 天塌了❗ 系统崩了❗ 快看啊,程序outOfMemoryError了🙈。下午老哥就领了大礼包💔


前言

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

快看啊,程序outOfMemoryError了🙈

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

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

排查过程

首先肯定是先看日志,根据日志信息可以看到三个关键信息:
1. 业务代码中调用了远程接口
2. 内存溢出outOfMemoryError
3. Arrays.copyOf(Arrays.java:3332)

猜想❔

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

  • 技术经理:调用远程接口没有设置超时时间,访问人数突然增多,导致请求阻塞。瞬间一万个请求进来,然后一个万的请求就阻塞了,从而导致内存溢出

  • 我的猜想:请求之前没有查询大量的数据,就算请求阻塞也不会占用大量内存,导致outOfMemory. 还有就是Tomcat的线程池也默认200,。就算一万个请求进来,同一时刻也最多处理200个请求,这个200个请求都阻塞的话会造成 系统卡死,但是不会出现outOfMemoryError

    虽然抛出了一个业务代码的错误,但是并不能肯定就是它引发的outOfMemoryError,也可能是其他任务占了太多内存,这个请求只是一根“稻草”

解决过程和方案✔

  1. 修改启动命令,导出堆信息
    定位outOfMemoryError 还得用证据说话呀! 让技术经理在启动命令上加了如下参数-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=./heapdump.hprof 再次出现内存溢出就会将堆信息导出。

  2. 分析堆信息,定位大内存对象
    因为之前已经装过分析dump文件的工具了,我用的是Intellij Profiler工具,打开堆快照文件如下:

    根本问题已经浮出水面了,KbResultSetList<UnionCustomerCheckLog>这两个对象几乎把内存撑满了,jvm 堆内存最大1024M 这两个就占了700M. 算是定位到问题了吧! 也推翻了技术经理说的调用远程接口大量请求被阻塞的问题。

  3. 查找GC回收日志
    我们搜索自己的业务包名字就行了,这样就能很快定位关键问题。发现存在service 名称 和 上面大对象的名称一致UnionCustomerCheckLog

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

  4. 定位问题代码 、分析代码
    找到关键代码之后我们就看看代码吧:

    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);
    }
    
  5. 解决问题
    既然上面已经分析出问题所在了,就是Android老哥还不太会分组统计,就把数据全部查询到内存中统计。导致outOfMemoryError.
    解决方法修改统计,改成SQL分组统计就行了:

    程序逻辑也相应的调整就行了。

总结

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

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

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

转载链接:https://juejin.cn/post/7473303204153311241


Tags:


本篇评论 —— 揽流光,涤眉霜,清露烈酒一口话苍茫。


    声明:参照站内规则,不文明言论将会删除,谢谢合作。


      最新评论




ABOUT ME

Blogger:袅袅牧童 | Arkin

Ido:PHP攻城狮

WeChat:nnmutong

Email:nnmutong@icloud.com

标签云