连接池泄露问题解决

前言

我们这边的项目的连接池使用的Hikari，连接连的是sparkThriftserver。但随着项目越来越大，发现用一阵子，连接就扩大到160甚至更多。

解决问题

1、排查连接情况

我们使用

netstat -nat | grep -i 10001 | wc -l

来查看连接此端口的TCP连接情况。

2、Hikari局限以及选用druid

我们在调查连接泄露的问题时候出现了麻烦。项目过大，每个人都说自己的连接都关闭了，排查代码显得很艰难。Hikari虽然号称最快，也最轻量，但是对于连接泄露这块显得没有办法。

druid连接池在这时候是更好的选择了。在 https://github.com/alibaba/druid/wiki/%E8%BF%9E%E6%8E%A5%E6%B3%84%E6%BC%8F%E7%9B%91%E6%B5%8B 文章中，讲了关于druid 对于检测泄露提供的方法。

//监控泄露的配置
dataSource.setRemoveAbandoned(true);
dataSource.setRemoveAbandonedTimeout(600);
dataSource.setLogAbandoned(true);

这些配置可以将泄露的连接强制关闭，并将泄露连接的堆栈信息都打印出来。这样就会方法到底是哪个方法调用而没有关闭连接。

3、日志记录

在日志记录这里我们可以使用logback针对DruidDataSource这个类来专门进行记录，并且只要ERROR级别的记录并将它写到文件里面，具体如下所示(只粘贴相关部分配置)

   <!-- 查看druid连接池ERROR的日志(来查看连接泄露的情况) -->
    <appender name="ERROR_LOG"  class="ch.qos.logback.core.rolling.RollingFileAppender">
        <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">
            <!--日志文件输出的文件名-->
            <FileNamePattern>${LOG_HOME}/datascience.poolerror.log.%d{yyyy-MM-dd}.log</FileNamePattern>
            <!--日志文件保留天数-->
            <MaxHistory>30</MaxHistory>
        </rollingPolicy>
        <encoder class="ch.qos.logback.classic.encoder.PatternLayoutEncoder">
            <!--格式化输出：%d表示日期，%thread表示线程名，%-5level：级别从左显示5个字符宽度%msg：日志消息，%n是换行符-->
            <pattern>%d{yyyy-MM-dd HH:mm:ss.SSS} [%thread] %-5level %logger{50} - %msg%n</pattern>
        </encoder>
        <!--日志文件最大的大小-->
        <triggeringPolicy class="ch.qos.logback.core.rolling.SizeBasedTriggeringPolicy">
            <MaxFileSize>10MB</MaxFileSize>
        </triggeringPolicy>
    </appender>

    <logger name="com.alibaba.druid.pool.DruidDataSource" additivity="false" level="ERROR">
        <appender-ref ref="ERROR_LOG"></appender-ref>
    </logger>