连接池

为什么要用连接池

相比于 SQL 执行的时间（不考虑慢 SQL），创建数据库连接的操作可谓相当昂贵，频繁的打开和关闭数据库连接，会导致系统性能非常低下。连接池可以缓存已经创建的连接，在需要连接时，从连接池中获取一个空闲连接，在使用过后将连接归还连接池。

关于连接池的大小应该如何设置，可以参考 关于数据库连接池，你可能做错了。

使用连接池时期望的行为

• 配置固定数目连接池后，数据库中连接数目能保持不变
• 数据库重启后，连接池能帮助应用自动重新创建好连接

MySQL

wait_timeout

MySQL 的 wait_timeout 变量用来控制 MySQL 主动关闭空闲连接的时间，单位秒，默认 8 小时。

为了实验方便，将此值改为 35 秒，可通过启动参数或配置文件进行指定，或使用此 docker-compose.yml 文件启动 MySQL。

$ docker-compose up -d mysql

此时创建的数据库连接，在空闲超过 35 秒时会被 MySQL 主动关闭：

在这种情况下，当前主流的 Java 连接池如何保证连接池数量固定

HikariCP

使用 HikariCP 的默认配置，如在 HikariCP Demo 中执行 ./gradlew bootRun，观察连接数变化情况：

可以看到，虽然 HikariCP 默认的配置 是 minimumIdle = maximumPoolSize = 10，但在超过 wait_timeout 设置的时间后，数据库连接被关闭了，并且连接池没有再将 minimumIdle 数目的连接建立起来。

这时数据库如果发生了重启，连接池也同样不会主动建立连接。

在 MySQL Connector/J 中，有一个 autoReconnect 属性，可以加到 jdbc 连接串上，但这个属性并不会改变上述的情况，并且官方也并不建议启用这个属性。

结论1：HikariCP 在默认配置下，两个期望行为均不能保证。

HikariCP 提供了一个 keepaliveTime 参数，来主动尝试保持连接可用：

⏳keepaliveTime

This property controls how frequently HikariCP will attempt to keep a connection alive, in order to prevent it from being timed out by the database or network infrastructure. This value must be less than the maxLifetime value. A “keepalive” will only occur on an idle connection. When the time arrives for a “keepalive” against a given connection, that connection will be removed from the pool, “pinged”, and then returned to the pool. The ‘ping’ is one of either: invocation of the JDBC4 isValid() method, or execution of the connectionTestQuery. Typically, the duration out-of-the-pool should be measured in single digit milliseconds or even sub-millisecond, and therefore should have little or no noticible performance impact. The minimum allowed value is 30000ms (30 seconds), but a value in the range of minutes is most desirable. Default: 0 (disabled)

让我们加上这个参数：

$ diff src/main/resources/application.properties src/main/resources/application-keepalive.properties
4c4,6
< spring.datasource.driverClassName=com.mysql.cj.jdbc.Driver
\ No newline at end of file
---
> spring.datasource.driverClassName=com.mysql.cj.jdbc.Driver
>
> spring.datasource.hikari.keepalive-time=30000
\ No newline at end of file

启动应用：

$ ./gradlew bootRun -Pprofile=keepalive

再观察一下效果：

MySQL 重启之后：

结论2：HikariCP 在启用 keepaliveTime 配置后，两个期望行为均能完美保证。

注意：根据 HikariCP 文档描述，keepaliveTime 默认不启用，允许设置的最小值是 30 秒，但建议设置到分钟级别，另外还需综合考虑数据库超时、重启或网络问题导致的连接中断，也不宜设置到小时级别。

Druid

类似的，我们可以通过 Druid Demo 来观察 Druid 连接池的行为。

先以默认配置启动应用：

$ ./gradlew bootRun

在默认配置中，同样使用了固定尺寸（initial-size = max-active = min-idle = 10）的连接池：

重启 MySQL 同样不会主动创建连接。

结论1：Druid 在默认配置下，两个期望行为均不能保证。

在 Druid 的 DruidDataSource配置属性列表 中，我们同样找到了 keepAlive 属性，默认也是未开启的：

配置	缺省值	说明
keepAlive	false（1.0.28）	连接池中的minIdle数量以内的连接，空闲时间超过minEvictableIdleTimeMillis，则会执行keepAlive操作。

然而按照文档中描述的与 keepAlive 属性相关的值进行设置：

spring.datasource.druid.min-idle=10
spring.datasource.druid.keep-alive=true
spring.datasource.druid.min-evictableIdle-time-millis=30000

依然无法保持数据库中固定的连接数。

在 Druid 的最新发布版 1.2.6 中，提到：

修复连接池在MySQL服务器主动连接断开时keepAlive机制失效的问题 #4227

不过按照上述配置依然无效。

经过反复测试，keepalive 机制的生效，除将 keepAlive 设置为 true 外，还需添加一个文档中并未描述的隐藏属性 keepAliveBetweenTimeMillis（最小值为 30000）。另外为了匹配 wait_timeout，将 timeBetweenEvictionRunsMillis 的值从默认一分钟调小：

spring.datasource.druid.keep-alive=true
spring.datasource.druid.keep-alive-between-time-millis=30000
spring.datasource.druid.time-between-eviction-runs-millis=15000

观察此配置下连接数情况：

$ ./gradlew bootRun -Pprofile=keepalive

相比 HikariCP，keepAlive 相关属性的定义略显混乱，理解和配置起来难度也更大。

虽然能维持住连接了，但对比 HikariCP 的直线，Druid 的连接数显得有些波动。当遇到 MySQL 重启时，波动更为明显：

结论2：Druid 在启用 keepAlive 相关配置后，能够主动维持连接数，但在遇到 MySQL 重启等中断情况时，连接数的保持不是很稳定，需要根据实际环境的配置进行具体调整，才能达到理想的状态。