JavaSQLException处理：重试与回滚实战技巧

本文深入剖析Java中SQLException的精准处理之道，强调摒弃简单粗暴的e.printStackTrace()，转而通过getSQLState()和getErrorCode()组合判断错误本质，针对性记录SQL语句、参数及数据库特有状态码；明确只有“08S01”“40001”等可重试错误才应配合资源清理、指数退避与事务外隔离进行有限重试；指出手动回滚前必须校验事务活跃性与连接状态，避免“No transaction in progress”等误操作；并严正警告PreparedStatement中null值处理不当引发的空指针与SQL注入风险，力推setObject/setNull统一方案、彻底禁用字符串拼接——每一条都是生产环境血泪经验凝结的实战铁律。

SQLException捕获后直接e.printStackTrace()会丢掉关键上下文

Java里遇到SQLException，很多人第一反应是e.printStackTrace()——这会让错误日志只保留堆栈，但丢失SQL语句、绑定参数、数据库状态码等调试必需信息。尤其在连接池超时或死锁场景下，光看堆栈根本没法定位是哪条语句、哪个事务卡住了。

• 用SQLException.getSQLState()判断错误类别（比如"08S01"是连接中断，"40001"是死锁）
• 用SQLException.getErrorCode()获取数据库特有码（MySQL常用1205表示死锁，PostgreSQL用40001）
• 记录前缀日志：SQL语句 + 参数列表 + e.getSQLState() + e.getErrorCode()
• 避免在catch块里吞掉异常又不记录——哪怕只是log.warn("DB op failed", e)也比printStackTrace强

重试逻辑不能套在try-catch外层无差别重试

把整个DAO方法包进for循环反复执行，看似简单，实则危险。比如插入唯一键冲突（SQLState="23000"）、语法错误（SQLState="42000"），重试只会重复失败；而网络闪断（SQLState="08S01"）或死锁（SQLState="40001"）才适合有限重试。

• 只对可重试错误码做重试："08S01"（连接异常）、"40001"（死锁）、"57P01"（PostgreSQL连接终止）
• 重试前必须显式关闭Statement/ResultSet，否则可能泄漏连接（尤其用Druid/Hikari时）
• 重试间隔建议用指数退避（如100ms → 300ms → 900ms），避免雪崩式重连
• 别在事务内重试——一旦Connection已标记rollback-only，后续操作全抛SQLException: Connection is closed

手动回滚前必须检查事务是否active

调用connection.rollback()前没确认事务状态，容易触发SQLException: No transaction in progress。常见于：连接被连接池回收、超时自动回滚、或上层框架（如Spring）已接管事务管理。

• 先查connection.getAutoCommit() == false，再查connection.isClosed() == false
• 若用JDBC原生事务，回滚后务必调用connection.setAutoCommit(true)恢复默认状态
• Spring项目中，别在service层手动rollback()——交给@Transactional(rollbackFor = ...)更安全
• 注意：MySQL的INSERT ... ON DUPLICATE KEY UPDATE成功执行但影响行为0，不算异常，也不该触发回滚

PreparedStatement参数为null时引发的空指针与SQL注入风险

用ps.setString(i, null)没问题，但若传入未判空的String变量（比如ps.setString(1, user.getName())），而user.getName()返回null，部分旧版JDBC驱动（如MySQL Connector/J 5.1.x）会抛NullPointerException而非正确设为SQL NULL；更糟的是，有人改用字符串拼接绕过——立刻引入SQL注入漏洞。

• 永远用setObject(i, value, Types.VARCHAR)替代setString(i, value)处理可能为null的字段
• 禁止拼接SQL："WHERE name = '" + name + "'" —— 即使加了name != null检查也不行
• 批量操作时，addBatch()前务必确保每个参数都经过setXxx设置，未设置的参数在某些驱动下默认为""而非NULL
• PostgreSQL对NULL类型推导更严格，建议显式指定setNull(i, Types.INTEGER)而非setObject(i, null)

本篇关于《JavaSQLException处理：重试与回滚实战技巧》的介绍就到此结束啦，但是学无止境，想要了解学习更多关于文章的相关知识，请关注golang学习网公众号！