sqlrecoverableexception并非自动修复异常，其“recoverable”仅表示程序可主动重试恢复，需开发者显式实现重连、重试逻辑，配合连接池剔除失效连接与幂等设计，避免盲目重试引发数据不一致。
SQLRecoverableException 不是可自动修复的异常，Java 中也没有内置机制能“自动修复”它。 它只是表示连接可能暂时中断（如网络闪断、数据库重启），应用有机会通过重试恢复，但修复动作（如重连、重执行）必须由开发者显式编写逻辑来完成。
为什么叫“Recoverable”？
这个名称强调的是：异常发生后，程序不一定需要崩溃，而是可以主动尝试恢复。是否真能恢复，取决于具体原因和你的处理策略：
- 数据库临时不可达 → 重连 + 重试 SQL 可能成功
- 连接被防火墙强制关闭 → 捕获后新建连接通常可行
- 事务已回滚或连接处于不一致状态 → 盲目重试可能出错，需先清理上下文
- 根本性故障（如数据库宕机数小时）→ 重试无意义，应降级或告警
典型应对方式：手动重试 + 连接重建
标准做法是捕获该异常，在业务允许范围内进行有限次重试，并确保使用新连接：
- 不要复用原 Connection 或 PreparedStatement（它们大概率已失效）
- 每次重试前获取新连接（从数据源或 DriverManager）
- 控制重试次数（如 1~3 次）和间隔（如 100ms~1s），避免雪崩
- 对非幂等操作（如 INSERT），需考虑重复执行风险，必要时加唯一约束或业务去重
借助框架简化处理
Spring JDBC 和 Spring Boot 提供了更便捷的支持：
- @Retryable（配合 Spring Retry）可声明式实现重试逻辑
- DataSourceUtils.getConnection() 等工具类能更好管理连接生命周期
- HikariCP 等连接池本身会检测并剔除失效连接，但不替你重试业务 SQL
不能依赖“自动修复”的常见误区
有人误以为设置了某个 JDBC 参数（如 autoReconnect=true）就能让驱动自动恢复所有场景——这是过时且不可靠的理解：
- MySQL Connector/J 8.0+ 已移除 autoReconnect，官方明确不推荐
- 即使旧版本开启，也仅对极少数底层连接异常有效，无法处理事务中断、语句失效等问题
- JDBC 规范未定义“自动修复”，所有恢复行为都属于应用层职责
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
