排查HikariDataSource异常关闭问题

笔者所有文章第一时间发布于:
hhbbz的个人博客

Hikari简单介绍

官网地址

快速,简单,可靠的数据源,spring boot2.0 已经将 HikariCP 做为了默认的数据源链接池,在官网测试中秒杀一切其他数据源,比如 commons-dbcp,tomcat,c3po,druid。

基本设计

Hikari 链接池采用了很多优化来提高并发数,可参考这里
所有数据库链接池都遵守基本的设计规则,实现 javax.sql.DataSource 接口,里面最重要的方法就是 Connection getConnection () throws SQLException; 用于获取一个 Connection, 一个 Connection 就是一个数据库链接,就是一个 TCP 链接,建立 TCP 链接是需要进行 3 次握手的,这降低来链接的使用效率,也是各种数据库链接池存在的原因。

数据库链接池通过事先建立好 Connection 并缓存起来,这样应用需要做数据查询的时候,直接从缓存中拿到 Connection 就可以使用来。数据库链接池还能够检测异常的链接,释放闲置的链接。

HikariDataSource

Hikari 中提供的 DataSource 是 HikariDataSource ,HikariDataSource 实现了 HikariConfig,和数据库的各种参数超时时间配置就正 HikariaConfig 中。

其中提供两种初始化方式,一种是默认的构造函数,单 new 一个 HikariDataSource 时,数据源的链接不会建立,需要等到第一次调用 HikariDataSource 的 getConnection 方法。数据源建立后的相关信息保存在 HikariDataSource 中变量 HikariPool pool。

另一种建立方式是调用带有 HikariConfig 的构造函数,这种方式适合多个数据源的建立,共享同一份配置。 这种方式在调用构造函数的时候就建立了数据源的链接。

HikariDataSource 的所有数据源获取都委托给了 HikariPool,一个数据源会有一个 HikariPool,一个 HikariPool 中有一个 ConcurrentBag,一个 ConcurrentBag 中多个 PoolEntry,一个 PoolEntry 对应一个 Connection。

问题描述

前段时间做的一个数据平台在最近总是莫名其妙出现

Caused by:
java.sql.SQLException: HikariDataSource HikariDataSource (HikariPool-2) has been closed.

这种错误。按字面意思来说就是使用连接池里的连接执行sql之前,这个连接池就已经被关闭了无法使用。

因为是会有很多数据源配置通过数据平台来连接数据库的,连接数非常庞大,很难管理,也会容易出现这种因为遗漏逻辑代码而导致的问题。所以在处理大量的数据库连接时候,务必要仔细仔细再仔细。“连接风暴”这种事情一旦发生,会压倒整个数据库服务器,直接影响当前业务,甚至所有业务。

问题跟踪

在找问题的时候,我们要看清楚控制台输出的堆栈信息和调用链,除了关注自己本身的业务代码之外,也要去关注调用链经过的框架/工具。

因为这个问题会涉及到数据库方面,所以数据库那一边的参数以及资源情况我们也要去关注,看到底是程序连接泄漏还是数据库给的连接数实在是太少。

模拟场景确认问题

在通过报错信息,异常产生的调用链以及所涉及资源的使用情况、参数配置之后,就要开始根据自己的猜想去编写代码,模拟bug触发的场景去确认我们的问题了。

封装一个简单的HikariDataSource

    public HikariDataSource initDataSource(){
        HikariDataSource dataSource = new HikariDataSource();
        dataSource.setConnectionTestQuery("SELECT 1");
        dataSource.setConnectionTimeout(60000);
        dataSource.setMinimumIdle(2);
        dataSource.setMaximumPoolSize(100);
        dataSource.setMaxLifetime(600000);
        dataSource.setValidationTimeout(5000);
        dataSource.setIdleTimeout(300000);
        dataSource.setLeakDetectionThreshold(500000);

        dataSource.setDriverClassName("com.mysql.jdbc.Driver");
        dataSource.setJdbcUrl("jdbc:mysql://127.0.0.1:3306/anymarket_dev?useSSL=false&characterEncoding=utf8&allowPublicKeyRetrieval=true");
        dataSource.setUsername("root");
        dataSource.setPassword("hbz961005");
        return dataSource;
    }

使用构造的数据源进行查询

    @Test
    public void testHikari() throws InterruptedException {
        HikariDataSource dataSource = initDataSource();

        JdbcTemplate jdbcTemplate = new JdbcTemplate(dataSource);

        jdbcTemplate.execute("select * from clocd_type");

    }

这样的操作是正常使用的,没有问题,但是我们的报错有异常关闭数据源连接,所以我们下一步就要开始加一句close数据源,再执行看看。

基于上面的测试代码进行改造,增加关闭数据源代码。

    @Test
    public void testHikari() throws InterruptedException {
        HikariDataSource dataSource = initDataSource();

        JdbcTemplate jdbcTemplate = new JdbcTemplate(dataSource);

        jdbcTemplate.execute("select * from clocd_type");

        dataSource.close();

        jdbcTemplate.execute("select * from clocd_type");
    }

执行,这个时候控制台就报出了

Caused by:
java.sql.SQLException: HikariDataSource HikariDataSource (HikariPool-2) has been closed.

这跟我们数据平台遇到的错误是一样的。

自此,我们已经验证出来了导致问题的所在:
jdbcTemplate是基于初始化出来的dataSource构造出来的,那么当我们的dataSoource关闭之后,
我们再使用原先的jdbcTemplate去进行查询,那就会有问题,因为里面的连接已经被我们关闭了。

问题已经验证出来了,那么接下来就是解决问题。

解决代码

基于上面的测试代码,补上重新构造新的datasource代码,重新设置当前jdbcTemplate。

    @Test
    public void testHikari() throws InterruptedException {
        HikariDataSource dataSource = initDataSource();

        JdbcTemplate jdbcTemplate = new JdbcTemplate(dataSource);

        jdbcTemplate.execute("select * from clocd_type");

        dataSource.close();

        dataSource = initDataSource();

        jdbcTemplate = new JdbcTemplate(dataSource);

        jdbcTemplate.execute("select * from clocd_type");
    }

这样就不会再报错了。

把问题回溯到业务代码中

我们已经知道了这个报错产生的原因以及解决方式了,那么我们就要去检查我们的业务代码。很明显业务代码报这个错的原因就是关闭连接后,没有重新构造连接,并设置给jdbcTemplate,所以只需要在业务代码中补上这个解决的逻辑即可。

结尾

这篇文章主要说明从一个复杂的业务平台中,把异常抽离出来,并使用简单的测试类/单元测试去进行模拟场景去验证问题,验证问题的产生原因以及找到解决方法,并最后把解决思路回归到业务代码中进行检查。

这种报错还是比较简单的,很好验证。如果是遇到因为线程安全、批量并发和中间件等所导致的bug,那么我们大概率要借助工具去进行问题跟踪了。这里笔者推几个工具:

  1. alibaba arthas
  2. jmeter
  3. qunar bistoury

这些都是挺不错的bug跟踪验证工具,大家可以去了解一下。

©著作权归作者所有,转载或内容合作请联系作者
禁止转载,如需转载请通过简信或评论联系作者。
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 217,542评论 6 504
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 92,822评论 3 394
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 163,912评论 0 354
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 58,449评论 1 293
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 67,500评论 6 392
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 51,370评论 1 302
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 40,193评论 3 418
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 39,074评论 0 276
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 45,505评论 1 314
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 37,722评论 3 335
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 39,841评论 1 348
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 35,569评论 5 345
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 41,168评论 3 328
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 31,783评论 0 22
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 32,918评论 1 269
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 47,962评论 2 370
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 44,781评论 2 354

推荐阅读更多精彩内容