应将资源清理与业务逻辑彻底分离，finally仅执行无副作用的关闭操作；优先使用try-with-resources自动管理jdbc资源；事务控制必须在业务路径中显式处理，不可置于finally。
杜绝在finally块中进行复杂的数据库操作，核心是把“清理”和“业务”彻底分开——finally只做释放，不做查询、更新、提交或回滚等任何依赖状态、可能失败、需要判断的逻辑。
用try-with-resources替代手动关闭
现代Java（JDK 7+）中，所有标准JDBC资源（Connection、PreparedStatement、ResultSet）都实现了AutoCloseable接口。直接用try-with-resources声明资源，close()会自动执行，无需手写finally：
- 避免了显式null判空、嵌套try-catch、关闭顺序错误等问题
- 若多个资源关闭时抛异常，只有第一个异常被抛出，其余会被addSuppressed，不丢失上下文
- 代码更短、可读性高，且天然规避了在finally里塞业务逻辑的冲动
把数据库事务控制移出finally
事务提交（commit）或回滚（rollback）不是“资源释放”，而是业务决策，必须放在业务逻辑路径中，不能丢进finally：
- 如果在finally里无条件commit，异常时也会提交脏数据
- 如果在finally里无条件rollback，正常流程反而被中断
- 正确做法：try中执行完业务后显式commit；catch中根据策略决定是否rollback（例如只对特定异常回滚）
清理逻辑必须原子、无副作用、不抛异常
真正该留在finally里的，仅限于确定能快速完成、不会改变程序状态、也不会因失败导致后续步骤失效的操作：
- 调用connection.close()——但前提是connection非null且未关闭过
- 每个close()单独包裹try-catch，记录warn日志，绝不向上抛异常
- 避免在finally里调用connection.rollback()、connection.setAutoCommit()等方法
- 更安全的做法：把close封装成工具方法（如DbUtils.closeQuietly(conn)），并在catch和正常return前统一调用
旧项目改造建议
若受限于JDK版本或框架无法用try-with-resources，仍需手写finally，务必遵守以下约束：
- finally中只出现close()调用，不出现executeUpdate()、next()、getString()等任何业务方法
- 关闭顺序严格为：ResultSet → Statement/PreparedStatement → Connection
- 每个close前判空，每个close后捕获SQLException并log.warn，不throw、不return
- 把重复的关闭逻辑抽成static工具方法，避免各处散落相似代码
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
