setAutoCommit(false)仅关闭自动提交，事务实际始于首条DML执行；必须显式commit()生效，否则连接关闭时静默回滚；rollback()仅对未提交更改有效且不可部分回滚，需用Savepoint实现局部回滚；连接池中需每次获取后重置autoCommit状态，避免事务状态污染。
setAutoCommit(false) 后必须显式 commit()，否则事务不生效
默认情况下 Connection 是自动提交模式（autoCommit = true），每条 SQL 执行完立刻持久化。想用事务，第一件事就是调用 setAutoCommit(false) —— 但这只是“开启事务”的开关，不是“启动事务”的动作。真正让数据库进入事务状态，靠的是第一条 DML 语句（如 INSERT、UPDATE）执行的那一刻。
常见错误是：设了 setAutoCommit(false)，中间执行了 SQL，但忘了调用 connection.commit()，最后连接关闭或 GC 回收，事务无声回滚。Java 不会替你兜底，数据库也不会报错。
- 务必在业务逻辑成功后调用
connection.commit() - 务必在 catch 块中调用
connection.rollback()，不能只依赖 finally - 不要在
finally里无条件commit()或rollback()，容易覆盖业务判断
rollback() 只对未 commit 的更改有效，且不能部分回滚
rollback() 会撤销从上一次 commit() 或 rollback() 之后的所有更改，回到事务起点。它不是“撤回上一条 SQL”，也不是“按行回滚”。一旦 commit() 成功，再调 rollback() 就无效了，还会抛 SQLException（如 MySQL 报 “No transaction is active”）。
典型误用场景：循环插入多条记录，想在某条失败时只回滚当前这条——做不到。JDBC 事务是连接级的原子单位，没有保存点（Savepoint）就只能全退。
- 需要部分回滚？得用
connection.setSavepoint()+connection.rollback(savepoint) - 使用
Savepoint后，仍需最终commit()或rollback()，否则事务悬而未决 - 某些旧版驱动（如 MySQL Connector/J 5.1 之前）对
Savepoint支持不完整，注意驱动版本
连接关闭时 autoCommit 状态不会自动恢复
调用 setAutoCommit(false) 改变的是当前 Connection 实例的状态，和连接池无关。如果用的是 HikariCP、Druid 等连接池，归还连接时，这个 false 状态会被带回去——下个借到它的线程，getAutoCommit() 返回仍是 false，极可能引发诡异的事务堆积或静默失败。
这不是 bug，是 JDBC 规范行为。连接池无法也不该自动重置事务状态，因为“是否该重置”取决于业务语义。
- 最稳妥做法：每次从连接池获取
Connection后，显式调用connection.setAutoCommit(true)（如果确定不需要事务） - 或者更推荐：统一用 try-with-resources + 显式
setAutoCommit(false)/commit()/rollback()，确保每个业务单元自包含 - 别依赖连接池的
resetConnectionOnReturn类似配置——很多池不提供，且语义模糊
MySQL 默认隔离级别下，rollback 不影响已加锁的间隙（Gap Lock）
在 MySQL InnoDB 中，即使你 rollback() 了事务，某些锁（尤其是可重复读 REPEATABLE READ 下的间隙锁）可能还没立即释放，导致后续相同条件的 SELECT ... FOR UPDATE 或插入被阻塞。这不是 JDBC 的问题，但开发者常误以为 “回滚完了就万事大吉”。
表现往往是：A 事务 rollback 后，B 事务卡在 insert 上，查 SHOW ENGINE INNODB STATUS 发现还有锁残留。
- 锁释放时机由存储引擎控制，JDBC 层无感知也无干预能力
- 避免长事务，减少锁持有时间；必要时考虑降低隔离级别（如改用
READ COMMITTED） - 别在事务里做耗时操作（如 HTTP 调用、文件读写），否则锁拖得越久，冲突概率越高
