java jdbc事务中commit和rollback需显式控制：先setautocommit(false)，复用同一连接，dml执行后才真正开启事务；成功则commit()，异常则catch中rollback()，finally释放资源，否则静默回滚或锁泄漏。

Java JDBC 事务的 commit 和 rollback 不是“调用了就生效”，而是依赖于明确的事务边界控制和连接状态管理。核心在于：关闭自动提交、复用同一连接、在正确时机显式提交或回滚，并妥善释放资源。

关闭自动提交是前提

默认情况下，JDBC 连接处于 autoCommit = true 状态，每条 SQL 都会立即持久化，无法形成事务。必须在执行业务 SQL 前调用：

• connection.setAutoCommit(false) —— 这只是开启手动事务的开关，不是事务起点
• 真正事务开始于第一条 DML（INSERT/UPDATE/DELETE）语句执行时
• 若使用连接池（如 HikariCP），该设置会影响后续借出的连接，务必在归还前重置为 true，避免状态污染

commit() 必须显式调用且仅一次

成功完成所有业务操作后，需主动提交才能将变更写入数据库：

Java Development Manual

Java开发手册规约集合，基于阿里巴巴Java开发手册（嵩山版）。 涵盖7大维度：编程规约、异常日志、单元测试、安全规约、MySQL数据库、工程结构、设计规约。 当用户需要：(1) 编写或审查Java代码 (2) 检查命名/代码规范 (3) 处理异常和日志 (4) 编写单元测试 (5) 安全编码 (6) 数据库设...

下载

• 调用 connection.commit() 后，事务正式结束，数据永久保存
• 若忘记调用，连接关闭时事务会静默回滚，无任何异常提示
• 重复调用 commit() 会抛 SQLException（如 “No transaction is active”）
• 提交后不能再 rollback()，否则报错

rollback() 要在异常分支中精准触发

回滚不是兜底操作，必须在捕获到异常且确认事务仍活跃时执行：

• 只在 catch 块中 调用 rollback()，不要放在 finally 里（否则正常流程也会被回滚）
• 调用前建议判断：conn != null && !conn.isClosed() && !conn.getAutoCommit()
• 回滚后可选调用 conn.setAutoCommit(true) 恢复默认状态，提升安全性
• rollback() 是全量回滚，不能撤销某一条语句；如需局部回滚，要用 Savepoint

完整流程不能漏掉资源清理

一个健壮的手动事务处理结构应包含三段逻辑：

• try 块：设 autoCommit=false → 执行 SQL → commit()
• catch 块：检查连接有效性 → rollback() → 记录日志
• finally 块：关闭 PreparedStatement / Statement → 关闭 Connection（不在此处 commit 或 rollback）

Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南