线上异常处理(一): 线程堆积导致OOM, RabbitMQ的Connection中自动创建线程池

布碗

于 2019-07-21 16:18:16 发布

阅读量3.3k

点赞数 2

分类专栏：异常处理文章标签： OOM RabbitMQ AMQConnection jstack jmap

本文链接：https://blog.csdn.net/sinat_36553913/article/details/96705227

版权

这篇博客记录了一次线上项目因线程数过多引发的OOM问题的排查过程。问题源于RabbitMQ的AMQConnection在创建Consumer时，每个Consumer对应一个线程池，导致线程堆积。通过jstack和jmap分析，找到问题根源在于封装类的线程封闭方式。解决方案是限制消费者数量以减少线程创建，同时提出利用Channel实现并发消费以提高吞吐量。

摘要由CSDN通过智能技术生成

说明

本篇博文主要记录之前线上项目由于线程数过多导致内存溢出后，事故原因的分析排查过程。项目背景是其中使用了公司封装的管理类来操作RabbitMQ。

正文

初步猜想

项目出现oom后发现是线程数过多导致内存泄露，快速进行了重启。重启后，仍发现线程数在不断地增长。查看代码发现，在从mq获取到消息后会进行http请求调用其他服务。查看工具类，发现每次请求都会新建CloseableHttpClient对象，请求完成后调用close()方法关闭连接。所以怀疑是连接没有关闭导致线程泄露。

对此，我们修改了工具类，创建CloseableHttpClient单例对象，并且使用连接池管理，自定义线程保活策略。设置最大连接数为50，默认最大单路径连接数为5，连接最长存活10s。

private static final int MAX_TOTAL = 50;

private static final int DEFAULT_MAX_PERROUTE = 5;

private static final int KEEP_ALIVE_TIMEOUT = 10 * 1000;

private static CloseableHttpClient HTTP_CLIENT;

static {
    PoolingHttpClientConnectionManager connectionManager = new PoolingHttpClientConnectionManager();
    connectionManager.setMaxTotal(MAX_TOTAL);
    connectionManager.setDefaultMaxPerRoute(DEFAULT_MAX_PERROUT