一 、问题描述

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

      }

    }

  }

四、问题解决

 （1）将执行异步操作的过程设置会无序的，这样的话vertx框架会创建一个线程池，用于执行任务

 （2）自己创建一个固定大小的线程池用于执行任务，类似方案（1）