OOM问题分析定位

最新推荐文章于 2024-03-17 23:38:37 发布

代码搬运工

最新推荐文章于 2024-03-17 23:38:37 发布

阅读量805

点赞数 1

分类专栏： java基础文章标签： oom java

本文链接：https://blog.csdn.net/weixin_38780073/article/details/104428428

版权

java基础专栏收录该内容

8 篇文章 0 订阅

订阅专栏

一、问题描述

二、MAT（Memory Analyzer Tool）分析

一、问题描述

直接上图，这个是之前在测试环境上发现的问题，导致整个服务崩了。（心里暗喜，幸亏是测试环境啊，上线那不得...）从打印的日志可以很清楚的知道啥原因，OOM嘛

java堆内存溢出原因：内存泄漏或者堆的大小设置不当引起的。对于内存泄露，需要通过内存监控软件查找程序中的泄露代码，而堆大小可以通过虚拟机参数-Xms,-Xmx等修改。

问题分析：

（1）这个服务在测试环境跑了这么久，都没出现这种情况，应该可以排除堆的大小设置不当的原因（正常操作应该是查看堆大小的设置情况进行排查问题，当时抖机灵了hhhh）

（2）在5分钟前，我刚刚发了一个版本到测试环境，就出现这问题，感觉大概率是代码问题

话不多说，赶紧分析一波代码。但是，为了假装自己是一个比较在行的程序员，还是按流程办事吧，先搞个dump文件，分析是哪里出现问题了。

二、MAT（Memory Analyzer Tool）分析

1.下载地址

https://www.eclipse.org/mat/downloads.php

2.获取dump文件

登录服务器，进入到bin目录下，用java自带的jmap命令生成dump文件，命令如下：

./jmap -dump:format=b,file=/home/xxxxx/heap.hprof pid(进程id)

3.Leak Suspect报告

从报告中，可以清楚的看到 io/vertx/core/impl/TaskQueue 这个类中的一个属性 java/util/LinkedList 类型的，占用了60.83%内存，往上看，这个还是跟kafka消费有点关系。

4.Chart报告

这个图也可以清晰的看到，java/util/LinkedList这个类型占用了较高的内存，那这个肯定是问题的隐患所在嘛。

三、代码问题

1.代码逻辑很简单，当有消息写入的时候，则利用vertx框架的异步操作处理逻辑。

vertx.executeBlocking(future->{
    /**
     * 业务代码逻辑
     */
},null);

2.查看这个异步操作的执行过程

（1）VertxInternal 接口 Vertx 接口；VertxImpl 类实现了 VertxInternal 接口，并重写了 executeBlocking方法

（2）executeBlocking方法分析

两个接口的区别之处在于，多了个order参数（是否有序），我的代码是调用了下面的接口，默认是有序执行。我们在仔细的品一品上面这个方法的实现。ContextImpl 、ContextImpl、ContextImpl 这个类不就是打印的日志中报oom的类嘛是，说明距离真相已经很近了。

我们在仔细的看一下这个方法的具体实现，里面有这么一段代码。这个queue就是我们之前报告分析中的TaskQueue。当我们设置了order=true的时候，会创建一个TaskQueue，用于按序存放要执行的任务；同时，由于是按序执行任务，vertx框架只会创建一个工作线程来处理业务逻辑，用于保证有序执行任务。在测试环境只有一台机器，也就是只有一个消费者，而我们的生产者大概是一分钟产生2w条数据，导致TaskQueue中的 tasks 添加了较多的任务而出现OOM。

 private final LinkedList<Task> tasks = new LinkedList<>();

ContextImpl 类中的executeBlocking方法

  if (queue != null) {
        queue.execute(command, exec);
      } else {
        exec.execute(command);
      }

TaskQueue类中的execute方法

public void execute(Runnable task, Executor executor) {
    synchronized (tasks) {
      tasks.add(new Task(task, executor));
      if (current == null) {
        current = executor;
        executor.execute(runner);
      }
    }
  }