本质是应用在指定超时时间内无法从连接池获取可用连接,需排查连接池耗尽、连接泄漏、数据库响应慢或网络问题,并结合jmx/actuator监控active/idle/pending_threads等指标定位根因。

当 HikariCP 报错 Connection is not available, request timed out after Xms,本质是应用在指定超时时间内无法从连接池获取到可用连接。这不是数据库宕了,而是连接被耗尽或卡住了——排查要围绕“为什么连不上”展开,重点看池配置、连接泄漏、数据库侧瓶颈。
检查连接池是否真的被耗尽
启用 HikariCP 的监控指标(如 JMX 或 Actuator),查看实时状态:
- active:当前正在被使用的连接数
- idle:空闲可立即分配的连接数
- total:池中总连接数(= active + idle)
- pending_threads:正在等待连接的线程数(关键!非零说明有线程卡住)
如果 active == maximumPoolSize 且 pending_threads 持续增长,说明连接全被占满且没释放,大概率存在连接泄漏或慢查询阻塞。
定位连接未释放(连接泄漏)
HikariCP 默认开启连接泄漏检测(需显式配置):
application.ymlspring:
datasource:
hikari:
# 开启泄漏检测,30秒后未归还即报警(单位:毫秒)
leak-detection-threshold: 30000
# 建议同时开启日志,输出堆栈
log-level: DEBUG
一旦触发泄漏告警,日志会打印持有连接未关闭的线程堆栈,直接定位到哪段代码忘了 close() 或没用 try-with-resources。
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
常见漏点:
- JDBC
Connection/Statement/ResultSet手动创建但未finally close() - Spring 中使用
JdbcTemplate一般安全,但若手动调用getConnection()就必须自己管理 - 异步任务(如
@Async)中访问数据库,上下文切换导致事务/连接未正确清理
确认数据库端是否响应慢或拒绝新连接
即使连接池配置合理,数据库扛不住也会导致“拿不到连接”:
- 查数据库当前连接数:
show status like 'Threads_connected';(MySQL),对比max_connections - 看慢查询:
show full processlist;,观察是否有大量Sleep或长时间Query状态 - 网络层面:telnet 或 nc 测试应用服务器到 DB 的端口是否通,延迟是否高
- DB 负载:CPU、IO、锁等待(如 MySQL
show engine innodb status)
特别注意:如果 DB 主从延迟大、读写分离路由异常,也可能让部分请求卡在不可用节点上。
核对 HikariCP 关键参数是否合理
别只调大 maximumPoolSize,先看是否匹配实际负载:
- connection-timeout:默认 30s,太长会让线程卡太久;建议设为 1~5s,配合上游超时控制
-
maximum-pool-size:不是越大越好,建议 ≤ 数据库
max_connections × 0.7,并考虑服务实例数 -
idle-timeout 和 max-lifetime:避免连接因 DB 主动断开(如 MySQL
wait_timeout)而失效,建议设为比 DB 值小 30 秒 - validation-timeout 和 connection-test-query(旧版)或 connection-init-sql:确保连接有效性,避免拿到已断开的连接
一个典型健康配置参考(MySQL,中等负载):
application.ymlspring:
datasource:
hikari:
connection-timeout: 3000
validation-timeout: 3000
idle-timeout: 600000
max-lifetime: 1800000
maximum-pool-size: 20
minimum-idle: 5
connection-init-sql: SELECT 1Java免费学习笔记:立即使用
解锁 Java 大师之旅:从入门到精通的终极指南










