在java jdbc中，通过connection.setautocommit(false)关闭自动提交是实现手动事务控制的基础方式，需在获取连接后、执行dml前调用，随后显式commit或rollback，并在finally中正确释放资源。
在 Java JDBC 中，通过 Connection.setAutoCommit(false) 关闭自动提交，是实现手动事务控制最基础、最直接的方式。它让开发者完全掌握事务的边界——从开启到提交或回滚，均由代码显式控制。
关闭自动提交开启事务
默认情况下，JDBC 连接处于自动提交模式（autoCommit = true），每条 SQL 执行后立即生效。要进入手动事务管理，必须在执行业务 SQL 前调用：
-
connection.setAutoCommit(false)—— 此操作会隐式结束上一个事务（如有），并开启一个新的事务上下文 - 该调用必须在获取
Connection后、执行任何 DML（INSERT/UPDATE/DELETE）前完成，否则已执行语句可能已被自动提交 - 若连接来自连接池（如 HikariCP、Druid），需确保在每次从池中获取连接后检查并设置该状态，因为连接被归还时通常会重置为 autoCommit=true
执行业务逻辑并决定提交或回滚
关闭自动提交后，所有后续 SQL 都在同一个事务中累积，直到显式提交或回滚：
- 成功场景：调用
connection.commit()持久化全部变更，事务结束，连接恢复为“就绪”状态（但 autoCommit 仍为 false，需手动重置或复用时注意） - 异常场景：捕获 SQLException 或业务异常后，必须调用
connection.rollback()撤销未提交的修改，避免脏数据残留 - 务必在
finally或 try-with-resources 的 close 前处理 commit/rollback，否则事务悬而未决，可能造成连接占用、锁等待甚至死锁
正确释放资源与状态清理
手动事务不等于忽略连接生命周期管理：
- 无论成功或失败，都应在 finally 块或 try-with-resources 中关闭 Statement 和 ResultSet，并优先确保 connection.rollback() 或 commit() 已执行
- 如果连接要归还给池，建议在归还前调用
connection.setAutoCommit(true)，避免下次借用者受遗留状态影响（部分连接池会自动重置，但不依赖此行为更安全） - 不要在事务过程中调用
setAutoCommit(true)—— 这会强制提交当前事务，且无法撤销，属于危险操作
典型代码结构示例
以下是一个健壮的手动事务模板（省略具体 SQL 和异常分类）：
Connection conn = null;
PreparedStatement stmt = null;
try {
conn = dataSource.getConnection();
conn.setAutoCommit(false); // 关键：关闭自动提交
stmt = conn.prepareStatement("UPDATE account SET balance = ? WHERE id = ?");
stmt.setDouble(1, newBalance);
stmt.setInt(2, accountId);
stmt.executeUpdate();
// 其他相关操作……
conn.commit(); // 显式提交
} catch (SQLException e) {
if (conn != null) {
try {
conn.rollback(); // 出错时回滚
} catch (SQLException rollbackEx) {
// 记录 rollback 失败日志，但不可抛出覆盖原异常
}
}
throw e;
} finally {
if (stmt != null) stmt.close();
if (conn != null) conn.close(); // 归还连接前，连接池通常会重置 autoCommit
}Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
