setAutoCommit(false) 必须在获取Connection后立即调用，因事务边界由连接控制，且部分驱动（如MySQL）在执行SQL后调用会报错；连接池状态不可靠，显式设置可避免事务污染与异常失效。
setAutoCommit(false) 为什么必须在获取 Connection 后立刻调用
因为 JDBC 的事务边界由 Connection 实例控制，而 setAutoCommit(false) 是开启手动事务的开关——它只对当前连接生效，且一旦执行过任何 SQL（哪怕只是 SELECT），再调用它就可能被某些驱动忽略或抛出异常（如 MySQL Connector/J 在已执行语句后调用会报 SQLException: Can't call setAutoCommit() while a transaction is active）。
实操建议：
- 务必在
connection = dataSource.getConnection()之后、任何Statement或PreparedStatement创建之前调用connection.setAutoCommit(false) - 不要依赖连接池返回的连接“默认是 auto-commit=true”——有些池（如 HikariCP）会重置状态，但有些（如旧版 DBCP）可能保留上一次使用后的状态，显式设置更可靠
- 如果用了 Spring 的
@Transactional，底层其实也做了这一步，但纯 JDBC 场景下漏掉这行，所有executeUpdate()都会立即提交，事务形同虚设
commit() 和 rollback() 的调用时机与异常捕获要点
事务是否成功，取决于你有没有在正确位置调用 commit()，以及有没有在异常路径上兜底 rollback()。漏掉任意一个，都可能导致数据不一致或连接卡在未结束事务状态。
常见错误现象：
立即学习“Java免费学习笔记（深入）”；
- 只写了
commit()，没写catch块里的rollback()→ SQL 报错后连接仍持有未提交事务，后续复用该连接可能触发锁等待或脏读 - 在
finally里调用commit()→ 即使前面 SQL 失败了也强行提交，逻辑彻底错乱 - 捕获了
SQLException却没检查connection.getAutoCommit()是否仍是 false → 某些驱动在失败后会自动重置 auto-commit 状态，导致后续rollback()无效
推荐写法骨架：
Connection conn = null;
try {
conn = dataSource.getConnection();
conn.setAutoCommit(false);
PreparedStatement ps1 = conn.prepareStatement("UPDATE ...");
ps1.executeUpdate();
PreparedStatement ps2 = conn.prepareStatement("INSERT ...");
ps2.executeUpdate();
conn.commit(); // 成功才提交
} catch (SQLException e) {
if (conn != null) {
try { conn.rollback(); } catch (SQLException ignored) {}
}
throw e;
} finally {
if (conn != null) {
try { conn.setAutoCommit(true); } catch (SQLException ignored) {}
conn.close();
}
}
多个 update/insert/delete 混用时，prepareStatement 的参数绑定与顺序依赖
事务本身不关心 SQL 类型，但业务逻辑常有强顺序依赖：比如先 INSERT INTO orders，再用生成的 order_id 去 INSERT INTO order_items。这时候不能只靠事务包裹，还得确保主键能被正确获取和传递。
使用场景与注意事项：
- MySQL 中用
Statement.RETURN_GENERATED_KEYS+getGeneratedKeys()获取自增 ID，必须在同一个Connection下完成，否则事务隔离会导致刚插入的记录在另一个连接中不可见 - Oracle 需用
RETURNING子句（如INSERT INTO t VALUES(?) RETURNING id INTO ?），同样依赖同一连接上下文 - 如果某条 SQL 因约束冲突（如唯一键重复）失败，后续语句不会执行，但已执行的语句仍处于未提交状态——所以不是“全部成功或全部失败”，而是“按顺序执行，任一失败则需回滚前面所有”
连接池环境下 setAutoCommit(false) 的副作用与清理责任
连接池（如 HikariCP、Druid）默认会在归还连接时重置 autoCommit、isolation 等状态，但这**不保证一定发生**——尤其当连接因异常未正常 close，或被强制 evict 时，残留的 autoCommit=false 可能污染下一个使用者。
性能与兼容性影响：
- 某些数据库（如 PostgreSQL）在
autoCommit=false状态下长期空闲，会占用 backend 进程并持锁，被监控系统视为慢连接 - HikariCP 的
resetConnectionOnReturn=true（默认开启）可缓解，但不能替代代码层的显式恢复 - 最稳妥的做法是在
finally块中主动调用conn.setAutoCommit(true)，再close()；即使池做了重置，多设一次也没副作用
容易被忽略的是：事务控制不是“开了 auto-commit 就万事大吉”，它把状态管理责任完全交给了你——从开启、执行、提交/回滚，到连接释放前的状态清理，每一步都得自己盯住。稍有遗漏，问题往往延迟暴露，排查成本远高于写几行防御代码。
