数据库重启后连接池因缺乏服务端状态感知而分配僵尸连接，导致CommunicationsException或ORA-17002；需配置有效性验证（如SELECT 1）、合理设置max-lifetime与idle-timeout、启用泄露检测，并协同调优数据库端wait_timeout或SQLNET.EXPIRE_TIME。
数据库重启后，连接池里的连接大多已失效，但池子并不知情，继续分配“僵尸连接”，导致应用报错如 CommunicationsException 或 ORA-17002。这不是连接池坏了，而是它缺乏对服务端状态的感知能力。关键不是等出错再补救，而是让连接池具备主动识别和自动剔除失效连接的能力。
配置连接有效性验证
这是最直接有效的手段。连接池在把连接交给业务线程前，先执行一条轻量 SQL 检查其是否可用。
- HikariCP 推荐配置：
spring.datasource.hikari.connection-test-query=SELECT 1（MySQL）
spring.datasource.hikari.connection-test-query=SELECT 1 FROM DUAL（Oracle）
spring.datasource.hikari.validation-timeout=3000（校验超时，单位毫秒） - 必须同时开启校验开关：
spring.datasource.hikari.test-on-borrow=true（借出时校验）
spring.datasource.hikari.test-on-return=true（归还时也校验，防坏连接污染池）
控制连接生命周期与空闲时间
避免连接在池中“睡过头”，被数据库服务端主动断开。
deep-java-review
下载
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
-
max-lifetime 应小于数据库的
wait_timeout（MySQL 默认 28800 秒），建议设为 1800000（30 分钟） - idle-timeout 控制空闲连接存活时长，建议设为 600000（10 分钟），确保它比服务端超时早一步被回收
- 注意：HikariCP 的
idle-timeout只作用于超出minimum-idle的多余连接；若minimum-idle设得过高，这部分连接不会被空闲回收，更依赖max-lifetime
启用泄露检测与连接重连机制
数据库重启后，旧连接无法恢复，必须重建；而连接泄露会加速池枯竭，掩盖真实问题。
立即学习“Java免费学习笔记（深入）”；
- 开启泄露检测：
spring.datasource.hikari.leak-detection-threshold=60000（60 秒未归还即告警） - 允许连接池在失败后尝试重建：
HikariCP 默认支持自动重连，但需配合connection-init-sql（如SET NAMES utf8mb4）和合理的connection-timeout（建议 3000–5000ms） - 不建议依赖“重启应用”来恢复——这只能临时掩盖问题，且影响可用性
配合数据库端统一调优
单靠客户端配置不够，需和服务端参数协同。
- MySQL：将
wait_timeout从默认 8 小时下调至 1800–3600 秒（30–60 分钟），与连接池的max-lifetime形成安全差值 - Oracle：检查
SQLNET.EXPIRE_TIME，确保其大于连接池的idle-timeout，否则监听器会提前中断连接 - 所有数据库都应开启连接保活日志，便于故障复盘时确认是服务端主动断开，还是网络层丢包
