druid连接池引起的线程blocked

最新推荐文章于 2023-07-23 18:58:49 发布
最新推荐文章于 2023-07-23 18:58:49 发布
阅读量889 收藏 3
点赞数 2
文章标签： java jvm 数据库 开发语言
本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/qq_39478167/article/details/128617582
版权

一、前言

  最近在捣鼓演示应用的时候发现一个druid连接池引起的线程blocked问题。先声明下，这个问题是druid 1.1.23版本之前的一个bug，并不是说druid存在明显的性能问题。

  github上其实已经有相关的issue：https://github.com/alibaba/dr...；也可以关注下druid各版本的release信息：https://github.com/alibaba/dr...。image.png

  而我在发现这个问题的时候并不知道这其实是个已经修复了的bug，因此记录了一些分析过程的线索，今天主要分享下问题排查的思路。

二、Let‘s Go

(一)严重的Thread Blocked

  事情起源于准备客户演示环境时的一轮压测(验证环境)。在压测过程中，发现有一个访问数据库的接口响应时间异常的高，虽然故意做了循环查库【一次http请求，10次MySQL查询】的操作，但是对于只是进行简单查询的SQL来说，接口的响应时间显得很不正常。

  1. 首先检查了下应用服务的资源使用情况，一切正常；
  2. 检查jvm运行情况。在热点方法【方法消耗CPU资源的情况】中，看到zip压缩相关的方法始终在消耗CPU资源时排在首位：把方法调用链展开，发现是类加载引起的；【可以肯定，应用哪里肯定有问题】热点方法.png
  3. 线程dump，检查线程都在干什么，并看看类加载相关完整的线程栈。在thread dump中发现了大问题，97%的业务线程都处于blocked状态：image.png
  4. 分析线程dump，寻找blocked的主要原因。发现就是类加载操作导致的大量线程blocked。而类加载操作竟然是druid相关的方法导致的(后面会提到，其实连接检测导致的)；阻塞.png

  项目中使用的druid连接池部分配置参数：

initialSize: 5
    minIdle: 5
    maxIdle: 5
    maxActive: 5
    maxWait: 60000
    timeBetweenEvictionRunsMillis: 60000
    minEvictableIdleTimeMillis: 300000
    validationQuery: SELECT 1 FROM DUAL
    poolPreparedStatements: true
    testWhileIdle: true
    // 获取连接时检测
    testOnBorrow: true
    // 归还连接时检测
    testOnReturn: true
    #   配置监控统计拦截的filters，去掉后监控界面sql无法统计，'wall'用于防火墙
    filters: stat,wall,slf4j
    maxPoolPreparedStatementPerConnectionSize: 20
    useGlobalDataSourceStat: true
    connectionProperties: druid.stat.mergeSql=true;druid.stat.slowSqlMillis=1000

  可以看到，这边把连接检测的配置都加上，也就是在获取连接，归还连接，以及连接空闲阶段都会进行连接检测。【考虑到性能影响：一般不开启testOnReturn和testOnReturn，而使用testWhileIdle配合timeBetweenEvictionRunsMillis进行空闲连接检测】

  接下来，简单分析下druid的部分源码，以及druid 1.1.23版本之前的bug的相关源码。

tips🏎：可以直接跳转至下面 getLastPacketReceivedTimeMs章节，直接进入druid bug相关问题；

(二)连接检测部分源码

1. getConnectionDirect - 连接检测入口

  调用getConnection()获取连接后，最终会调用com.alibaba.druid.pool.DruidDataSource#getConnectionDirect方法。在getConnectionDirect方法中，就会判断是否走连接检测的逻辑，下面是主要源码(篇幅原因其他分支逻辑细节去掉了，可自行阅读)：

public DruidPooledConnection getConnectionDirect(long maxWaitMillis) throws SQLException {
        int notFullTimeoutRetryCnt = 0;
        for (;;) {
            // DruidPooledConnection封装了物理连接对象
            DruidPooledConnection poolableConnection;
            try {
                // 这是连接检测的核心代码所在
                poolableConnection = getConnectionInternal(maxWaitMillis);
            } catch (GetConnectionTimeoutException ex) {
                if (notFullTimeoutRetryCnt <= this.notFullTimeoutRetryCount && !isFull()) {
                    notFullTimeoutRetryCnt++;
                    if (LOG.isWarnEnabled()) {
                        LOG.warn("get connection timeout retry : " + notFullTimeoutRetryCnt);
                    }
                    continue;
                }
                throw ex;
            }
            // 是否开启了获取连接时检测(按照上面的配置，首先会进入这段代码)
            if (testOnBorrow) {
                boolean validate = testConnectionInternal(poolableConnection.holder, poolableConnection.conn);
                if (!validate) {
                    if (LOG.isDebugEnabled()) {
                        LOG.debug("skip not validate connection.");
                    }

                    discardConnection(poolableConnection.holder);
                    continue;
                }
            } else {
                if (poolableConnection.conn.isClosed()) {
                    discardConnection(poolableConnection.holder); // 传入null，避免重复关闭
                    continue;
                }
                // 是否开启了空闲检测，会根据空闲时间，判断是否进行连接检测
                if (testWhileIdle) {
                    // ......
                }
            }
            // 是否开启了removeAbandoned参数(不推荐开启，会获取线程栈信息)
            if (removeAbandoned) {
                // ......
            }

            if (!this.defaultAutoCommit) {
                poolableConnection.setAutoCommit(false);
            }

            return poolableConnection;
        }
    }
2. testConnectionInternal - 连接检测核心代码

  com.alibaba.druid.pool.DruidAbstractDataSource#testConnectionInternal是连接检测的核心代码。开启了testOnReturn和testOnReturn后，核心的连接测试逻辑都在这。

两个关键方法：

  1. validConnectionChecker.isValidConnection()，实际上调用的是com.alibaba.druid.pool.vendor.MySqlValidConnectionChecker#isValidConnection()。主要做两件事：1、先发送ping信息给mysql服务器，检测tcp连接可用性；2、执行validationQuery配置的SQL查询语句;
  2. MySqlUtils.getLastPacketReceivedTimeMs()，用于获取连接的空闲时间。这个方法也是今天thread blocked的元凶；
protected boolean testConnectionInternal(DruidConnectionHolder holder, Connection conn) {
    // ......其他
    try {
        if (validConnectionChecker != null) {
            // isValidConnection真正做检测的方法，会做两件事
            // 1. 先发送ping信息给mysql服务器，检测tcp连接可用性;
            // 2. 执行validationQuery配置的SQL查询语句;
            boolean valid = validConnectionChecker.isValidConnection(conn, validationQuery, validationQueryTimeout);
            long currentTimeMillis = System.currentTimeMillis();
            if (holder != null) {
                holder.lastValidTimeMillis = currentTimeMillis;
                holder.lastExecTimeMillis = currentTimeMillis;
            }
            // 如果是mysql数据库，且通过了连接测试，就进入下面的代码
            if (valid && isMySql) { // unexcepted branch
                // 1.1.23之前的bug所在
                long lastPacketReceivedTimeMs = MySqlUtils.getLastPacketReceivedTimeMs(conn);
                if (lastPacketReceivedTimeMs > 0) {
                    long mysqlIdleMillis = currentTimeMillis - lastPacketReceivedTimeMs;
                    if (lastPacketReceivedTimeMs > 0 //
                            && mysqlIdleMillis >= timeBetweenEvictionRunsMillis) {
                        discardConnection(holder);
                        String errorMsg = "discard long time none received connection. "
                                + ", jdbcUrl : " + jdbcUrl
                                + ", version : " + VERSION.getVersionNumber()
                                + ", lastPacketReceivedIdleMillis : " + mysqlIdleMillis;
                        LOG.warn(errorMsg);
                        return false;
                    }
                }
            }
            if (valid && onFatalError) {
                lock.lock();
                try {
                    if (onFatalError) {
                        onFatalError = false;
                    }
                } finally {
                    lock.unlock();
                }
            }
            return valid;
        }
        // ......其他
    }
}
3. getLastPacketReceivedTimeMs - 线程阻塞的元凶，bug所在

  com.alibaba.druid.util.MySqlUtils#getLastPacketReceivedTimeMs

  • 1.1.23版本之前的实现
/**
 * druid 1.1.23版本之前的源码实现
 */
public static long getLastPacketReceivedTimeMs(Connection conn) throws SQLException {
        // 第一次执行这段代码，class_connectionImpl是初始值null，因此会进入if逻辑
        if (class_connectionImpl == null && !class_connectionImpl_Error) {
        try {
            // 写死mysql-connector-java 5的类
            // 因此使用6+版本的驱动，会存在ClassNotFound的问题。
            class_connectionImpl = Utils.loadClass("com.mysql.jdbc.MySQLConnection");
        } catch (Throwable error){
        class_connectionImpl_Error = true;
        }
        }
}
  • 修复后的代码实现
    新增了对mysql-connector-java 6的支持；
/**
 * druid 1.1.23版本及之后的源码实现
 * @param conn ：如果配置了自定义Filter，传入的conn就是ConnectionProxyImpl类型，否则就是ConnectionImpl类型
 */
public static long getLastPacketReceivedTimeMs(Connection conn) throws SQLException {
        // 如果配置了自定义Filter，这边class_connectionImpl就是null
        if (class_connectionImpl == null && !class_connectionImpl_Error) {
            try {
                // 加载mysql连接类
                class_connectionImpl = Utils.loadClass("com.mysql.jdbc.MySQLConnection");
                if (class_connectionImpl == null) {
                    class_connectionImpl = Utils.loadClass("com.mysql.cj.MysqlConnection");
                    if (class_connectionImpl != null) {
                        mysqlJdbcVersion6 = true;
                    }
                }
            } catch (Throwable error) {
                class_connectionImpl_Error = true;
            }
        }
        .....
      }

  发现没有，其实主要问题是MySQL驱动包版本的问题，druid 1.1.23之前的版本是写死的mysql-connector-java 5的类名，如果工程中配置了com.mysql.cj.*相关的包，就会导致一系列的问题：

  1. loadClass是同步方法，多线程下导致线程阻塞；
  2. Spring Boot动态类加载的时候最终会调用其自定义类加载器LaunchedURLClassLoader，在加载过程中会遍历BOOT-INF/lib/ 下所有的 jar 包 以及 BOOT-INF/classes/下的字节码文件；【jar方式部署】
  3. 解析内部jar时，会进行解压缩操作；
  4. com.mysql.cj.*相关的包不存在，因此每次连接测试都会重复以上操作；

三、结尾

  码完了，也没什么别的想说的了。哈🤠，可以看看自己的druid版本，版本<1.1.23的话赶紧升级吧。 有问题欢迎留言讨论。

开翻挖掘机
关注
  • 2
    点赞
  • 踩
  • 3
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
德鲁伊Druid连接池.zip
02-03
druid-1.0.9.jar，druid-1.0.9-sources.jar，druid-1.0.9-javadoc.jar，druid.properties
Java线程的6种状态及切换(透彻讲解)
热门推荐
潘建南的博客
12-24 25万+
Java中线程的状态分为6种。 1. 初始(NEW)：新创建了一个线程对象，但还没有调用start()方法。 2. 运行(RUNNABLE)：Java线程中将就绪（ready）和运行中（running）两种状态笼统的称为“运行”。 线程对象创建后，其他线程(比如main线程）调用了该对象的start()方法。该状态的线程位于可运行线程池中，等待被线程调度选中，获取CPU的使用权，此时处于就绪状...
Druid无效链接回收策略(源码分析)(mysql 8小时连接失效问题)
做的过程自我总结
01-22 2946
目录 问题背景(异常Communications link failure) druid数据库连接池关键配置说明(注意标红配置) druid数据库连接池超时连接回收源码分析 第一种方式 : 获取连接时校验 第二种方式 : Destroy 定时任务检查需要被回收的连接 总结(线程回收几种配置方法) 参考资料 问题背景(异常Communications link failure) 最近添加了数据库监控后发现会有几十万分之一概率查询失败. 查看日志发现异常如下 :Caused b..
Java 线程状态之 BLOCKED
Just do IT
03-30 2175
深入探讨了 Java 线程的 BLOCKED 状态, 特别是对 enter 及 reenter 两种情形进行了深入分析.
druid报错 discard long time none received connection
夜星
03-31 5475
druid报错 discard long time none received connection
Jstack中线程thread的状态 BLOCKED,WAITING,TIMED_WAITING
Kirito_j的博客
07-02 4190
1.BLOCKED这种状态是指一个阻塞线程在等待monitor锁如：wait2.WAITING一个线程在等待另一个线程执行一个动作时在这个状态如：Object#wait() 而且不加超时参数Thread#join() 而且不加超时参数LockSupport#park()3.TIMED_WAITING一个线程在一个特定的等待时间内等待另一个线程完成一个动作会在这个状态如：Thread#sleep()...
druid连接池的jar包
01-27
Druid在数据摄入之前，首先要定义一个数据源（DataSource,类似于数据库中表的概念），Druid是一个分布式数据分析平台,也是一个时序数据库，也是一个集群系统，使用zookeeper做节点管理和事件监控。 Druid是一个专为...
tomcat连接池与阿里Druid连接池
10-25
Tomcat 连接池和阿里 Druid 连接池的配置和比较 Tomcat 连接池是一种基于 Java 的数据库连接池实现，提供了高效、可靠的数据库连接管理。阿里 Druid 连接池是阿里巴巴开发的开源连接池，提供了高性能、可靠的数据库...
jdbctemplate+druid连接池.docx
11-17
JdbcTemplate 和 Druid 连接池是 Java 中常用的两个数据库操作工具。JdbcTemplate 是 Spring 框架的一部分，提供了一种模板化的 JDBC 操作方式，简化了数据库访问，而 Druid 是阿里巴巴开源的一个高性能、功能丰富的...
druid数据库连接池jar包
05-19
Druid数据库连接池是一款高效、功能强大且高度可扩展的数据库连接池组件，由阿里巴巴开源并在众多项目中广泛应用。它的全称是Dynamic Routing Data Source，即动态路由数据源，旨在提供监控、性能统计、SQL审计等...
springboot 搭配的 的 druid最新版本 警告 discard long time none received connection. 问题
飞翔小猪的博客
04-15 4万+
在使用了新版的 druid-1.2.5 以后，日志中一直在报 Error，内容是 discard long time none received connection. , jdbcUrl : 巴拉巴拉，但程序运行并没有受到影响，但看着一大片错误就浑身难受，我决定去他们的源码里看看到底是怎么回事。网上搜索到的解决方案是回退到1.1.22可解决，但我觉得这样的解决方案有点傻X，不去想解决问题，而是倒车躲避。 看看源码是谁在报错 进到源码搜索这句「discard long time ...
数据库链接长时间无数据交互，发生线程阻塞情况
fannk的博客
11-03 1216
背景：  在执行双机房部署的时候，因为应用长时间未访问数据库，导致后面访问的数据库的线程都被挂起。   现象分析： "Thread-74" daemon prio=10 tid=0x00007f1840044000 nid=0x387b runnable [0x00007f18bdb27000] java.lang.Thread.State: RUNNABLE ...
Druid连接池连接泄露问题
大鱼
11-27 2万+
    使用springboot+Druid搭建的项目，项目中使用了多数据源；本来是核查列存数据库报错信息，结果看到了Oracle查询时错误信息。下面贴出错误截图 2018-05-08 21:33:11.582 WARN --- [pool-4-thread-1] c.alibaba.druid.pool.DruidDataSource : not full timeout retry : ...
druid连接池 - 长时间阻塞问题排查
Evan_L的博客
11-13 6454
前言 最近参与一个新项目，从老项目拷贝过来的代码，同样用的druid连接池 + PG。但是新项目却经常出现阻塞的情况，有时候甚至可以阻塞半个小时。一时间傻眼了。。 问题排查 问题背景 我们一共有6个开发同学，由于项目时间还是比较紧张的，所以大部分时间还是在开发，而不会发访问服务器。而当前阶段也还没有提测，没有其他同学的介入。而且每次第二天早上都会出现这种阻塞的情况。 请教DBA大佬 由于配置跟老项目一模一样，所以第一个反应是数据库出什么问题了？找DBA断断续续排查了好几天（太忙了，主要还是搞开发），最后发现
低版本Druid连接池+MySQL驱动8.0，在高并发下出现线程阻塞、性能受限问题
hxt的博客
06-12 3892
现象 应用升级MySQL驱动8.0后，在并发量较高时，查看监控打点，Druid连接池拿到连接并执行SQL的时间大部分都超过200ms 对系统进行压测，发现出现大量线程阻塞的情况，线程dump信息如下： "http-nio-5366-exec-48" #210 daemon prio=5 os_prio=0 tid=0x00000000023d0800 nid=0x3be9 waiting for monitor entry [0x00007fa4c1400000] java.lang.Thread.S
method:com.alibaba.druid.pool.DruidAbstractDataSource.testConnectionInternal问题解决
ggjklncffd的博客
07-23 824
你可以创建一个后台线程，定期检测连接的有效性，并在连接无效时将其废弃。不管你选择哪种方法，都需要确保在应用程序中实现合适的连接有效性检测，以确保连接池中的连接始终保持可靠和有效。，建议实施其他有效的连接有效性检测方法，例如设置合适的连接超时时间或使用合理的数据库查询来确认连接是否有效。这意味着即使数据库连接已经失效，连接池也不会立即知道，而继续使用失效的连接可能会导致异常或错误的数据库操作。：由于连接池不会自动检测连接的有效性，应用程序可能会在使用已失效连接时遇到数据库异常，例如连接超时或无效查询。
什么导致线程阻塞
ITJingYing2050的博客
06-15 1374
线程阻塞的引入： 为了解决共享存储区的访问冲突，Java引入了同步机制。显然光有同步机制是不够的，因为任意时刻所需的资源不一定准备好了，反过来，同一时刻准备好的资源也可能不止一个。为了应对这种情况，Java又引入了阻塞机制。 阻塞是指暂停某一线程的执行直到满足某一条件，才继续执行。 Java提供大量方法来支持阻塞，下面来逐一介绍。 sleep()：它使线程进入阻塞状态，失去CPU执行时间。指定时间一过，线程重新进入可执行状态。 suspend()和resume()：它们需要配套使用，suspend
线程阻塞原因分析介绍
路过的熊的博客
04-11 7494
导致线程阻塞的原因主要有以下几方面。 1、线程进行了休眠：线程执行了Thread.sleep(int n)方法，线程放弃CPU，睡眠n毫秒,然后恢复运行。 2、线程等待获取同步锁才能进行下一步操作：线程要执行一段同步代码，由于无法获得相关的同步锁，只好进入阻塞状态，等到获得了同步锁，才能恢复运行。 3、线程执行wait（）进入阻塞状态：线程执行了一个对象的wait()方法，进入阻塞状态，只有等到其他线程执行了该对象的notify()或notifyAll()方法，才可能将其唤醒。 4、等待相关资源：线程执行I
java thread一直 wait_Java线程状态Jstack线程状态BLOCKED/TIMED_WAITING/WAITING解释
weixin_42361478的博客
02-16 1383
一、线程5种状态新建状态(New) 新创建了一个线程对象。就绪状态(Runnable) 线程对象创建后，其他线程调用了该对象的start()方法。该状态的线程位于可运行线程池中，变得可运行，等待获取CPU的使用权。运行状态(Running) 就绪状态的线程获取了CPU，执行程序代码。阻塞状态(Blocked) 阻塞状态是线程因为某种原因放弃CPU使用权，暂时停止运行。直到线程进入就绪状态，才有机会...
druid连接池官方文档
最新发布
09-07
Druid连接池是一种高效、可扩展的Java数据库连接池，官方文档详细地介绍了Druid连接池的功能、配置和使用方法。 首先，文档介绍了Druid连接池的特点。Druid连接池具有高度可配置性，可以通过配置文件或者代码来设置连接池的参数，以适应不同的场景和需求。它还支持监控统计功能，可以实时监控连接池的使用情况，并提供详细信息和统计报表。此外，Druid连接池还支持防止恶意攻击、SQL注入等安全措施，以保护数据库的安全。 接下来，文档介绍了Druid连接池的配置方法。我们可以通过在配置文件中设置各种参数来配置连接池，例如设置初始化连接数、最大连接数、最小空闲连接数等。我们还可以配置连接的生命周期和验证策略，以及SQL统计功能等。Druid连接池还支持使用代码来动态配置连接池，这样可以更灵活地调整连接池的参数。 然后，文档介绍了使用Druid连接池的方法。我们可以通过通过简单的几行代码来获取连接，如"DataSource dataSource = DruidDataSourceFactory.createDataSource(properties);"。获取连接后，可以使用该连接来执行SQL操作，并在完成后释放连接。Druid连接池还支持连接的自动扩展和收缩功能，可以根据连接的需求动态地增加或释放连接。 最后，文档介绍了Druid连接池的监控统计功能。我们可以通过配置一些参数来开启监控功能，并可以通过配置URL来访问监控的信息。监控信息包括连接数量、连接状态、执行的SQL语句等详细信息，以便我们能够全面了解连接池的使用情况，及时发现和解决问题。 总而言之，Druid连接池官方文档详细介绍了Druid连接池的功能、配置和使用方法，帮助用户更好地了解和使用Druid连接池，提高系统的数据库访问效率和安全性。

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值