核心是主动适配连接中断：配置驱动重试（如SQL Server的connectRetryCount）、连接池预检（如HikariCP的connection-test-query）、应用层捕获08类错误码并指数退避重试，结合maxLifetime与connection-timeout保障连接活性与快速切换。
Java 中通过 JDBC 处理数据库服务重启后的恢复，核心不是“等它自己好”，而是主动适配连接中断场景——重点在于连接层的韧性设计和应用层的重试/回退策略。SQL Server、MySQL、HSQLDB 等主流数据库在服务短暂重启时，已建立的连接会断开，但新连接请求可能因服务未就绪而失败。JDBC 本身不自动“等待重启完成”，需靠配置与代码协同应对。
启用驱动内置连接重试（针对初始连接）
以 Microsoft SQL Server JDBC Driver（10.2.0+）为例，它支持 connectRetryCount 和 connectRetryInterval 两个连接字符串参数：
- connectRetryCount=3：表示最多尝试连接 3 次（含首次），失败后不再重试
- connectRetryInterval=5：每次重试前等待 5 秒
- 组合使用如：
jdbc:sqlserver://localhost;databaseName=test;connectRetryCount=3;connectRetryInterval=5 - 注意：该机制仅作用于 初始 getConnection() 调用，不适用于执行 SQL 过程中连接突然断开的情况
检测并静默恢复空闲连接（保持连接活性）
数据库重启后，连接池中已存在的“空闲连接”可能已失效（如被负载均衡器或防火墙切断）。JDBC 驱动可通过 keep-alive 机制识别并重建：
- SQL Server JDBC Driver 支持 sendStringParametersAsUnicode=false 等配合项，但更关键的是启用底层 TCP keepalive（依赖操作系统设置）
- 实际开发中，更推荐由连接池（如 HikariCP、Druid）承担此职责：配置 connection-test-query 或 validation-timeout，在借出连接前验证其有效性
- 例如 HikariCP 设置：
connection-test-query=SELECT 1（MySQL）或connection-test-query=SELECT 1 FROM SYSIBM.SYSDUMMY1（DB2），确保连接可用再交付业务使用
对执行失败语句做可配置重试（CRL 或自定义逻辑）
服务重启期间，正在执行的 SQL 可能因连接中断、超时或返回特定错误码（如 SQL Server 的 40613、MySQL 的 2006）而失败。此时需在应用层捕获异常并重试：
立即学习“Java免费学习笔记（深入）”；
- JDBC Driver 12.10+ 提供 可配置重试逻辑（CRL），支持按错误号（如 1205 死锁、40197 临时性错误）定义重试次数与退避策略
- 若使用旧版驱动或需更高控制力，可自行封装重试逻辑：用 while 循环 + try-catch + Thread.sleep，判断 SQLException.getSQLState() 或 getErrorCode()
- 示例关键判断：
e.getSQLState().startsWith("08") || e.getErrorCode() == 40613（常见连接类错误前缀）
配合连接池实现故障隔离与快速切换
单靠 JDBC 驱动不够，连接池是生产环境恢复能力的关键载体：
- 配置 maxLifetime（如 1800000ms = 30 分钟）：避免长期空闲连接在重启后仍被复用
- 启用 leakDetectionThreshold：及时发现连接未关闭问题，防止资源耗尽影响恢复
- 设置 connection-timeout（如 30s）：防止线程无限阻塞在不可达连接上
- 部分池（如 Druid）还支持 fail-fast 模式，在检测到连续失败后主动清空无效连接
