1. 背景

我们的mqtt服务线上一实例出现OOM，通过日志发现，OOM具体原因是因为没有足够空间创建新线程。

image.png

通过监控发现，该实例线程数一直缓慢增长，并没有回收。

image.png

2. 分析线程文件

jstack命令生成线程dump文件，通过分析，发现MQTT客户端创建了大量线程，并且没有释放。

image.png

3. 源码分析

服务使用的mqtt客户端如下

<dependency>
    <groupId>org.eclipse.paho</groupId>
    <artifactId>org.eclipse.paho.client.mqttv3</artifactId>
    <version>1.2.1</version>
</dependency>

使用方式如下：

image.png

主要问题出在对mqtt client连接处理的代码上。原有代码的连接过程大致如下：
新建一个MqttClient对象 --> 设置callback监听断连、收到消息和发送消息成功的回调逻辑 --> 调用connect()方法连接emqx broker --> 订阅topic。
在收到断连的回调消息后，会发起重连操作，把上述流程重走一遍

image.png

排查线上日志发现有不少断连，

image.png

问题在于每一次重连后，老的MqttClient对象没有close()掉。

一个client又会引用着4种线程，
1、ConnectBG：负责连接操作的
2、CommsReceiver：用于消息接收
3、CommsSender：用于消息发送
4、CommsCallback：执行回调通知

image.png

因此随着重连次数增加， 线程数也缓慢叠加。

4. 解决方案

断连后，旧的Mqttclient调用close()方法，关闭资源

5. 效果

发生重连前：

image.png

借用tcpkill，模拟关闭tcp连接。

image.png

日志显示已经发生了重连

image.png

重连前后的MQTT线程，旧的线程已经成功回收。

image.png

发布后线上环境的效果

image.png

参考：
Linux 使用tcpkill杀掉tcp连接