深入解析 Druid 连接池：连接有效性检测与 Keep-Alive 机制

揉幽递 · 2025-6-4 20:31:45

背景

在 Java 程序中，下面是一个经常会碰到的错误。

Caused by: com.mysql.cj.exceptions.CJCommunicationsException: Communications link failure The last packet successfully received from the server was 30,027 milliseconds ago. The last packet sent successfully to the server was 30,028 milliseconds ago.

复制代码

该错误通常是由于 MySQL 连接意外断开导致的，常见原因包括：

客户端连接池（如 HikariCP、Druid）配置不当，包括：
- 空闲连接超时时间超过 MySQL wait_timeout（默认是 28800 秒，即 8 小时），导致连接被 MySQL 服务端关闭。
- 未配置适当的 Keep-Alive 机制，导致连接长时间未使用而被 MySQL 服务器关闭。
- 未进行连接有效性检查，可能导致客户端获取到失效连接。
连接未及时释放。
长时间未释放的连接无法通过连接池的 Keep-Alive 机制保持活跃，更容易因空闲超时被 MySQL 服务端或中间件关闭。
中间层组件的超时限制。
如果客户端与 MySQL 之间存在代理（如 ProxySQL）或负载均衡器（LB），这些组件可能会有独立的空闲连接超时设置，导致连接被提前断开。
网络问题，包括高延迟、丢包或短暂网络中断都会影响数据库连接的稳定性。
连接被 MySQL 服务器主动断开，如 DBA 手动执行KILL操作终止连接。

本文将深入解析 Druid 连接池的连接有效性检测机制，重点探讨以下内容：

Druid 在哪些情况下会检查连接是否可用？
Druid 如何保持连接的活跃状态（Keep-Alive 机制）？
Druid 连接池中常见参数的具体含义及其作用。
为什么 MySQL 的 general log 看不到validationQuery定义的检测语句执行？

希望通过本篇分析，帮助大家更深入理解 Druid 连接池的运行机制。
什么场景下会检测连接的有效性

Druid 连接池在以下四种场景下会检测连接的有效性：

申请连接。
归还连接。
创建新的物理连接。
定期检测。

下面我们看看这四种场景的具体实现逻辑。
1. 申请连接

当应用从连接池申请空闲连接时，会检查连接的有效性，与之相关的参数有两个：testOnBorrow 和 testWhileIdle。
申请连接是在getConnectionDirect方法中实现的，下面我们看看该方法的具体实现细节。

public DruidPooledConnection getConnectionDirect(long maxWaitMillis) throws SQLException { int notFullTimeoutRetryCnt = 0; for (; ; ) { DruidPooledConnection poolableConnection; try { // 从连接池中获取空闲连接 poolableConnection = getConnectionInternal(maxWaitMillis); } catch (GetConnectionTimeoutException ex) { ... } // 如果testOnBorrow为true，则会调用testConnectionInternal检测连接的有效性 if (testOnBorrow) { boolean validated = testConnectionInternal(poolableConnection.holder, poolableConnection.conn); if (!validated) { if (LOG.isDebugEnabled()) { LOG.debug("skip not validated connection."); } // 如果连接无效，则会调用discardConnection丢弃该连接，并继续从连接池中获取新的空闲连接。 discardConnection(poolableConnection.holder); continue; } } else { ... // 如果testOnBorrow不为true，且testWhileIdle为true，则判断连接的空闲时间是否超过timeBetweenEvictionRunsMillis，如果超过，也会调用testConnectionInternal检测连接的有效性 if (testWhileIdle) { final DruidConnectionHolder holder = poolableConnection.holder; long currentTimeMillis = System.currentTimeMillis(); long lastActiveTimeMillis = holder.lastActiveTimeMillis; ... long idleMillis = currentTimeMillis - lastActiveTimeMillis; if (idleMillis >= timeBetweenEvictionRunsMillis || idleMillis < 0 // unexcepted branch ) { boolean validated = testConnectionInternal(poolableConnection.holder, poolableConnection.conn); if (!validated) { if (LOG.isDebugEnabled()) { LOG.debug("skip not validated connection."); } // 如果连接无效，则会调用discardConnection丢弃该连接，并继续从连接池中获取新的空闲连接。 discardConnection(poolableConnection.holder); continue; } } } } ... return poolableConnection; } }

复制代码

该方法的处理流程如下：

通过 checkCount = poolingCount - minIdle 计算当前池中可以回收的连接数量。其中minIdle是 Druid 参数，用于指定连接池需保留的最小空闲连接数。
遍历连接池中的连接，并执行以下检查：
- 物理连接存活时间检查：如果 phyTimeoutMillis > 0，检查物理连接的存活时长是否超过phyTimeoutMillis，如果超过，则将该连接加入销毁列表（evictConnections）。
- 空闲时间检查：如果连接的空闲时间大于 maxEvictableIdleTimeMillis，或空闲时间大于等于 minEvictableIdleTimeMillis 且连接的序号小于 checkCount（可回收连接数），则将该连接加入销毁列表。
- 保持连接活跃：若连接需要保持活跃（keepAlive开启）且空闲时间超过keepAliveBetweenTimeMillis，则将该连接加入 keepAliveConnections 列表。
将未被检查的连接移动到 remaining 之后的位置，确保有效连接的连续性。
如果 evictCount 大于 0，表示有连接需要销毁，遍历销毁列表（evictConnections）关闭这些连接。
如果 keepAliveCount 大于 0，表示有连接需要保持活跃，遍历 keepAliveConnections 列表，检查连接有效性，若有效，将其放回连接池。如果校验失败，则丢弃连接。
如果 needFill 为 true，表示连接池中空闲连接不足，触发填充信号以创建新连接。

所以，Druid 连接池默认情况下，每 60 秒（由 timeBetweenEvictionRunsMillis 参数控制）执行一次连接回收和维护操作，并保持一定数量的空闲连接。其核心逻辑包括：

回收超时或多余的空闲连接：
- 连接的空闲时间超过 maxEvictableIdleTimeMillis 或 phyConnectTimeMillis，将被回收。
- 当连接池的数量超过最小空闲连接数 minIdle 时，如果连接的空闲时间超过 minEvictableIdleTimeMillis，也会被回收。
维护 Keep-Alive 机制（如果keepAlive开启）：
- 当连接的空闲时间超过 keepAliveBetweenTimeMillis，且距离上次 Keep-Alive 检测时间超过 keepAliveBetweenTimeMillis 时，执行有效性检测。
- 通过 validateConnection 进行检测，合格的连接重新加入池中，不合格的连接被销毁。
必要时补充新的连接：
若当前连接数（activeCount + poolingCount）低于 minIdle，则触发连接补充机制，创建新的连接。

需要注意的是，即使连接开启了定期探活检测，若发生超时，仍会被回收。
接下来，我们看看上述参数的默认值：

timeBetweenEvictionRunsMillis：默认 60000 毫秒（60 秒）。
minEvictableIdleTimeMillis：默认 1800000 毫秒（30 分钟）。
maxEvictableIdleTimeMillis：默认 25200000 毫秒（7 小时）。
phyTimeoutMillis：默认 -1。
keepAlive：默认为 false。
keepAliveBetweenTimeMillis：默认 120000 毫秒（120 秒）。

为什么设置的 validationQuery 没有效果？

在 Druid 连接池中，判断连接是否有效时，通常调用 testConnectionInternal 或 validateConnection 方法。这两个方法的核心逻辑基本相同，具体如下：

优先使用 validConnectionChecker 进行连接校验：
- validConnectionChecker 是一个接口，定义了 isValidConnection 方法，用于检测数据库连接的有效性。
- 具体的数据库有对应的实现类，例如：MySQL 由MySqlValidConnectionChecker实现，Oracle 由 OracleValidConnectionChecker 实现。
- validConnectionChecker 在 initValidConnectionChecker 方法中初始化，并根据数据库驱动类型选择合适的实现类。
如果 validConnectionChecker 未初始化，则执行默认检查：
- 通过 validationQuery 执行 SQL 语句，验证连接是否有效。
- 该方法适用于所有数据库，但会带来一定的性能开销。

以下是 MySQL 实现类（MySqlValidConnectionChecker）中isValidConnection方法的具体实现。

// DruidDataSource.java protected void recycle(DruidPooledConnection pooledConnection) throws SQLException { final DruidConnectionHolder holder = pooledConnection.holder; ... if (testOnReturn) { boolean validated = testConnectionInternal(holder, physicalConnection); if (!validated) { JdbcUtils.close(physicalConnection); ... } } ... }

复制代码

方法中的 usePingMethod 受druid.mysql.usePingMethod参数控制，其默认值为 true。
当 usePingMethod 等于 true 时，validateQuery 将被设置为 DEFAULT_VALIDATION_QUERY，即/* ping */ SELECT 1，而非用户自定义的 validationQuery。
execValidQuery() 方法执行 validateQuery 时，如果查询语句以/* ping */开头，MySQL JDBC 驱动会进行特殊处理。
具体来说，MySQL JDBC 在解析 SQL 语句时，会判断它是否以 PING_MARKER（即/* ping */）开头，如果是，则不会执行 SQL 语句，而是调用doPingInstead()，直接向 MySQL 服务器发送 COM_PING 命令，这样可以减少 SQL 解析和执行的开销，提高性能。

public PhysicalConnectionInfo createPhysicalConnection() throws SQLException { String url = this.getUrl(); Properties connectProperties = getConnectProperties(); ... try { // 这里会调用驱动的 connect 方法来建立连接 conn = createPhysicalConnection(url, physicalConnectProperties); connectedNanos = System.nanoTime(); if (conn == null) { throw new SQLException("connect error, url " + url + ", driverClass " + this.driverClass); } ... if (!initSqls(conn, variables, globalVariables)) { validateConnection(conn); } ... } ... return new PhysicalConnectionInfo(conn, connectStartNanos, connectedNanos, initedNanos, validatedNanos, variables, globalVariables); }

复制代码

关于参数设置的几点建议

minEvictableIdleTimeMillis，maxEvictableIdleTimeMillis不宜设置过小，因为频繁销毁和创建连接会带来额外的性能开销。
建议开启 keepAlive 机制，尤其是在客户端与 MySQL 之间存在代理的情况下，这些组件可能会有独立的空闲连接超时设置，导致连接被提前断开。
在连接申请时检测连接的有效性（通过设置 testOnBorrow 为 true）是最有效的方式，可以确保每次获取的连接都是可用的。但这种方式会对应用性能产生一定影响，尤其是在高并发场景下。
因此，建议根据业务需求权衡性能与可靠性，选择合适的检测策略。
考虑到网络可能的故障，即使 Druid 连接池定期检测连接的有效性，也无法 100% 保证所有连接都可用，所以应用端一定要做好容错处理。
对于代码中未及时归还使用过的连接，一方面可能导致连接泄漏，使连接池耗尽可用连接。另一方面，未释放的连接无法通过 Druid 的 Keep-Alive 机制保持活跃状态，更容易因空闲超时被 MySQL 服务器或中间件关闭。
为了避免这些问题，建议在应用的测试环境开启以下参数来识别长时间未归还的连接：logAbandoned，removeAbandoned，removeAbandonedTimeoutMillis。

总结

Druid 连接池在以下四种场景下会检测连接的有效性：申请连接、归还连接、创建新物理连接以及定期检测。
Druid 通过开启 keepAlive 参数，定期对空闲连接进行有效性检测，确保连接保持活跃状态。
当连接的空闲时间超过 keepAliveBetweenTimeMillis 时，Druid 会触发 Keep-Alive 检测，验证连接的有效性。如果连接有效，则重新放回连接池；如果无效，则将其销毁。
Druid 默认使用 MySQL 的 COM_PING 命令进行连接有效性检测，这种方式比执行 SQL 语句更高效。
由于 COM_PING 的优先级高于用户自定义的 validationQuery，因此在默认配置下，validationQuery 不会被执行。
如果用户希望使用自定义的 validationQuery 进行连接检测，可将 druid.mysql.usePingMethod 参数设置为 false 来实现。

来源：程序园用户自行投稿发布，如果侵权，请联系站长删除
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！

账号		自动登录	找回密码
密码			立即注册