数据库连接池满的常见场景

同事碰到了一个问题，客户端和数据库服务端跨机房，防火墙将数据库连接断开了，客户端重连建立新连接，但是服务端没有清理老连接，导致连接池满。这个现象属于比较常见的一个场景。

尤其是生产环境可能设置严格的防火墙控制，对于数据库连接的检测和重连机制，就显得格外重要，一般是和连接池配置相关，无论用的什么连接池技术，Druid、Hikari...，相关的参数作用可以说大同小异，例如原始配置，

hikari:
maximum-pool-size:10  #最大连接数
max-lifetime:1800000  #连接最大存活时间
connection-test-query:select 1

仅设置了如下三个参数：

• maximum-pool-size:10
• max-lifetime:1800000
• connection-test-query:select 1

此时连接池的行为是：

• 没有主动检测空闲连接的有效性：仅在借出连接时（若开启 testOnBorrow，但未显式配置，HikariCP 默认仅在连接创建、借出或归还时有限验证）才会执行 connection-test-query。如果连接在池中空闲时已被防火墙断开，连接池并不知道，仍然认为这些连接可用。
• 连接回收依赖 max-lifetime：即使连接已失效，也要等 30 分钟（1800000ms）后才会被强制移除。在此期间，10 个连接可能全部变成"僵尸连接"，新的请求无法从池中获取有效连接，导致连接池"满"但实际不可用。

因此，需要增加一些参数配置，

hikari:
maximum-p0ol-size:10  #根据实际业务需求调整
minimum-idle: 5
idle-timeout: 300000
max-lifetime: 1800000
connection-timeout: 30000
keepalive-time: 30000
leak-detection-threshold: 180000
connection-test-query: select 1

新增加了这几个：

keepalive-time: 30000          # 30秒
idle-timeout: 300000           # 5分钟
connection-timeout: 30000      # 30秒
leak-detection-threshold: 180000  # 3分钟
minimum-idle: 5

其中 keepalive-time 是最直接解决防火墙断连问题的参数。

keepalive-time 的作用

• 定期检测空闲连接的有效性：HikariCP 会在后台线程中，每隔 keepalive-time 毫秒，对池中空闲超过该时间的连接执行 connection-test-query。
• 自动清理失效连接：如果检测失败（如连接已断），该连接会被立即从池中移除，并触发创建新连接（保持池大小）。
• 防止僵尸连接堆积：即使防火墙静默断开连接，池也能在 30 秒内发现并清理，确保连接池始终包含有效连接。

其它参数的辅助作用

• idle-timeout：将空闲超过 5 分钟的连接回收（但若连接已断，keepalive-time 会更早发现并清理）。
• connection-timeout：避免获取连接时无限等待，提升失败反馈速度。
• leak-detection-threshold：主要用于检测代码中连接未归还的泄漏问题，对防火墙断连导致的连接失效问题影响较小。
• minimum-idle：保持至少 5 个空闲连接，配合 keepalive-time 确保池中总有可用连接。

综上，keepalive-time 通过主动、定期验证空闲连接的有效性，及时剔除因防火墙断连而失效的连接，是解决"连接池满且不释放"问题的关键参数。

当然，其它参数（如 idle-timeout、connection-timeout）有各自的作用，提升了整体的连接管理健壮性，但如果没有 keepalive-time，池中仍可能长期堆积无效连接。