关键在于“在哪儿提交、由谁控制、是否在正确上下文中提交”：推荐使用Spring声明式事务（@Transactional），由框架自动管理commit/rollback；若手动管理，须严格遵循获取连接→禁用自动提交→复用同一连接→显式提交或回滚→归还连接的流程。

Java 中调用 commit() 提交事务本身不难，但真正保障业务数据一致性，关键不在“怎么写 commit()”，而在于“在哪儿提交、由谁控制、是否在正确上下文中提交”。直接裸调 connection.commit() 容易出错，尤其在多层调用、异常分支、连接复用（如连接池）场景下极易导致数据不一致或连接泄漏。

使用声明式事务（推荐 Spring @Transactional）

这是最常用也最安全的方式，由框架自动管理 commit/rollback，开发者只需关注业务逻辑。

• 在 Service 层方法上加 @Transactional 注解，Spring 会在方法正常结束时自动 commit；遇到未捕获的运行时异常（RuntimeException 及其子类）时自动 rollback
• 确保该方法被 Spring 容器管理（即通过注入调用，不是 new 出来的对象调用），否则注解无效
• 如需自定义回滚规则，可用 @Transactional(rollbackFor = Exception.class) 指定对受检异常也回滚
• 避免在事务方法内吞掉异常（如 try-catch 后不抛出），否则 Spring 无法感知失败，会错误 commit

手动管理事务（JDBC 原生方式）

适合简单脚本、测试或必须绕过框架的场景，但需严格遵循“获取连接 → 关闭自动提交 → 执行 SQL → 显式 commit/rollback → 关闭资源”流程。

JavaStoryDevelop

你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在

下载

• 从 DataSource 获取 Connection 后，立即调用 conn.setAutoCommit(false)
• 所有相关 SQL 操作（增删改）必须复用同一个 Connection 对象，不能跨连接
• 成功完成全部操作后，调用 conn.commit()；任一环节出错，必须在 catch 或 finally 中调用 conn.rollback()
• 务必在 finally 块中调用 conn.close()（连接池环境下实际是归还连接，非销毁）

注意事务边界与传播行为

多个事务方法相互调用时，传播行为决定新事务是否开启、如何嵌套，直接影响 commit 是否生效。

立即学习“Java免费学习笔记（深入）”；

• REQUIRED（默认）：有事务则加入，无则新建 —— 最常用，适合多数业务组合
• REQUIRES_NEW：总是挂起当前事务，新建独立事务 —— 适合日志记录、异步通知等需独立成败的子操作
• 避免 SUPPORTS 或 NOT_SUPPORTED 用于核心写操作，它们可能让关键更新脱离事务保护

常见一致性陷阱与规避

即使写了 commit()，仍可能因设计疏漏破坏一致性：

• 跨数据库操作无法靠单个 commit 保证原子性 —— 需用分布式事务（如 Seata、XA）或最终一致性方案（消息表 + 补偿）
• 事务中调用外部 HTTP 接口成功但 DB 写入失败，或反之 —— 应将外部调用移出事务，或引入本地消息表+可靠消息
• 同一事务内多次查询同一数据却得到不同结果（幻读/不可重复读）—— 根据隔离级别调整（如设为 REPEATABLE_READ），但注意性能影响
• 长时间事务阻塞其他操作 —— 拆分大事务，避免在事务中做耗时操作（如文件处理、远程调用）