连接池本身不自动感知数据库宕机，需通过testOnBorrow等验证机制剔除失效连接，并在getConnection时按需重建新连接；配合idleTimeout、maxLifetime及业务层异常兜底，实现快速恢复。

Java 数据库连接池本身不会自动“感知”数据库宕机并完成全量恢复，但可以通过合理配置和配套机制，在数据库重启后快速重建可用连接，避免应用持续报错或雪崩。关键不在于“等它自己恢复”，而在于让连接池主动剔除失效连接、及时建立新连接，并配合业务层做好容错。

连接池如何识别失效连接

连接池不能靠心跳包实时探测数据库是否存活，而是依赖“借用时验证”或“归还时校验”机制：

• testOnBorrow：每次从池中取连接前执行一条简单 SQL（如 SELECT 1），失败则丢弃该连接、尝试获取下一个
• testOnReturn：连接用完归还时验证，适合低频写+高频读场景，但会增加归还开销
• testWhileIdle：对空闲连接定期检测（需配合 timeBetweenEvictionRunsMillis），避免积压大量僵尸连接
• HikariCP 默认启用 connectionTestQuery（如 MySQL 用 SELECT 1）并推荐开启 isValid() 检查，比传统 ping 更可靠

数据库重启后连接池怎么重建连接

数据库服务恢复后，连接池不会立刻“刷新全部连接”，而是按需重建：

deep-java-review

Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...

下载

• 旧连接在被取出时验证失败，会被自动清除，不进入业务逻辑
• 后续 getConnection() 请求将触发新建物理连接，只要 JDBC URL、账号密码正确，就能连上新实例
• 若配置了 maxLifetime（如 HikariCP 默认 30 分钟），老化连接会自然淘汰，加速新连接覆盖
• 可手动触发 evictExpiredConnections()（HikariCP 无直接 API，但可通过 close() + recreate DataSource 实现强制刷新）

必须配合的预防性配置

光靠连接池自身不够，还需从三方面加固：

立即学习“Java免费学习笔记（深入）”；

• 缩短空闲连接生存周期：设置 idleTimeout（如 10 分钟），避免连接在数据库重启后长期滞留池中变成“幽灵连接”
• 限制连接最大寿命：maxLifetime 应略小于数据库 wait_timeout（如 DB 设为 28800 秒=8 小时，则 maxLifetime 设为 7 小时），防止连接被服务端静默断开
• 启用连接泄漏检测：leakDetectionThreshold（如 60000 毫秒），及时发现未 close 的连接，避免耗尽池子导致后续请求卡死

业务代码要配合做异常兜底

连接池再智能，也无法替代业务层对 SQLException 的合理响应：

• 捕获 SQLNonTransientConnectionException 或 SQLRecoverableException 后，不要重试同一 Connection，应立即释放并重新 getConnection()
• 涉及事务的操作，遇到连接类异常应主动 rollback，再根据幂等性判断是否重试整个业务流程
• 对非核心链路（如日志写入、统计上报），可降级为异步缓存+延后重试，避免因 DB 不可用拖垮主流程