开发排障笔记

深浅主题

HikariCP 连接池耗尽 ​

问题现象 ​

报 Connection is not available, request timed out，active 到达上限，pending 上升；数据库可能仍有剩余连接。

适用环境 ​

Spring Boot 3、HikariCP、MySQL 8；多实例应用。

本文是可复用的排障示例，不代表某次个人生产事故。命令中的名称、账号和数据均为示例，执行前请替换为已确认的目标。

复现或诊断步骤 ​

  1. 检查每个实例 active、idle、pending、acquire latency，而不只看全局总连接。
  2. 查看数据库长事务和正在执行的 SQL，区分慢查询、锁等待与连接泄漏。
  3. 在受控窗口启用合理的 leakDetectionThreshold，结合线程栈确认持有连接的位置；它只报告疑似长持有，不会回收连接。

原因分析 ​

事务包含远程请求或大循环导致连接持有过久，手工 JDBC 没有关闭连接，或实例数量乘以池大小超过数据库容量。connectionTimeout 是申请连接等待时间，不能终止已经执行的慢 SQL。

修复示例 ​

yaml
spring:
  datasource:
    hikari:
      maximum-pool-size: 12
      minimum-idle: 3
      connection-timeout: 3000
      max-lifetime: 1500000
      leak-detection-threshold: 20000
# 数值需结合数据库容量、连接寿命与正常事务时长评估

缩短事务中的非数据库工作，用 try-with-resources 关闭手工 Connection、Statement 与 ResultSet。池大小应在所有应用和管理连接的总预算内；maxLifetime 应低于基础设施强制断连时间，并保留余量。修改前保存原配置，分批部署并观察。

验证方法 ​

模拟慢查询和连接泄漏，确认等待超时可识别，恢复后 pending 下降。重复业务请求后 active 应回落，不应单调增加；监测数据库 CPU、锁与连接数。

常见误区 ​

把 connectionTimeout 改大只会让用户等更久。不要把 leak 日志等同永久泄漏，也不要默认数据库 max_connections 就是可并行高效执行的查询数。

官方参考链接 ​

相关分类：Java 后端 · 全部笔记