做 Java 后端的人几乎没有不认识Transactional的。但说实话真正把这一个注解用明白、用对的人比想象中少很多。我见过不少同事在 Service 方法上随手加一个Transactional就以为万事大吉结果线上数据出现莫名其妙的不一致排查半天才发现事务压根没生效或者回滚范围和预期完全不是一回事。这篇文章不打算堆砌理论就围绕 Spring Boot 里的声明式事务把我实际配置Transactional的完整思路、核心参数选型、踩过的坑和排查方法一次说清楚。Transactional是 Spring 提供的声明式事务管理注解核心价值只有一个把事务边界从业务代码里剥离出来让你不用手写begin、commit、rollback那堆样板代码。在 Spring Boot 中只要依赖和数据源配好你就能直接在 Service 方法上使用这个注解框架会在方法执行前后自动帮你开启、提交或回滚事务。这篇文章适合两类人一类是刚接触 Spring Boot想搞清楚事务到底该怎么写才正确的新手另一类是已经写过不少Transactional但被事务失效、回滚不掉、大事务拖垮性能等问题折磨过的同学。我会从最基础的事务概念讲起用一个完整的转账案例带着你把事务跑通再把经典的失效场景和排查清单整理成干货最后聊一些生产环境里的避坑经验。1. 事务管理基础先从“为什么”说起1.1 事务的四个特性以及你到底需要哪几个在 Java 后端的事务语境里ACID 这四个字绕不开。原子性Atomicity保证一个事务里的所有操作要么全部成功要么全部失败一致性Consistency保证事务结束后数据仍然满足业务规则隔离性Isolation保证并发事务之间互不干扰持久性Durability保证事务提交后数据不丢失。这里我不打算背定义说个实际的感受日常开发里你真正关注的其实是原子性和隔离性。原子性决定了一个业务流程中间某一步挂了前面已经执行的数据库操作要不要撤销隔离性决定了多个请求同时读写同一批数据时会不会读到脏数据、重复数据。一致性和持久性更多是数据库层面和硬件层面保证的应用层能干预的空间不大。所以你在写Transactional的时候脑子里要始终绷着一根弦这段逻辑中间如果抛异常了之前执行的 SQL 到底要不要撤销如果需要那就说明这段逻辑应该放进一个事务里。很多事务失效的问题根子不在写法上而是开发者压根没想清楚哪些操作是一个不可分割的整体。1.2 声明式事务与编程式事务为什么注解是首选Spring 里做事务管理有两条路编程式事务和声明式事务。编程式事务就是用TransactionTemplate或者直接操作PlatformTransactionManager在代码里自己控制开始、提交、回滚。声明式事务就是今天的主角Transactional把事务边界声明在方法上具体的开启和关闭交给 Spring 的 AOP 代理去处理。声明式事务的优势很明显你的业务代码里看不到一行事务控制代码阅读和后续维护都清爽得多。举个例子转账方法里你只需要写扣钱、加钱两个业务动作至于什么时候开事务、什么时候提交、什么异常要回滚全部由注解上的配置和框架机制决定。编程式事务虽然控制粒度更细灵活性更高但代码侵入性强一旦散落在多处很容易出现某个分支忘了提交或回滚的问题。在实际项目中我的建议是常规业务优先使用声明式事务不确定边界或者需要在同一方法里多次控制事务的时候再用TransactionTemplate兜底。注意一点Transactional默认是加在方法上的因为它在 Service 层通常意味着“一个完整的业务用例”粒度刚刚好。加在 Controller 上不是不行但我强烈不建议Controller 的主要职责是参数校验和结果封装把事务放在这一层会让业务边界变得模糊。1.3 Spring Boot 中的自动装配为什么不用配置就能用用过传统 Spring 的同学应该记得早年配置事务需要先声明一个DataSourceTransactionManager再在 XML 里写tx:annotation-driven或者加EnableTransactionManagement。到了 Spring Boot 时代这些几乎都被自动配置接管了。你只要在 pom 里引入spring-boot-starter-jdbc或者spring-boot-starter-data-jpaSpring Boot 会通过TransactionAutoConfiguration自动注册DataSourceTransactionManager同时把事务注解的解析开关打开。也就是说你在 Service 方法上直接写Transactional就能生效不需要额外加任何开关。对 MyBatis 用户来说也是一样MyBatis 的 Spring Boot Starter 配置好之后底层仍然是DataSourceTransactionManager事务行为由同一个机制管理。这个“开箱即用”的体验确实省事但也带来一个副作用很多人因为太顺手了反而没搞懂背后到底发生了什么。一旦遇到事务不生效就容易手足无措。所以下一节我先带你把Transactional的每个参数吃透再来讲它内部是怎么运作的。2. 核心参数拆解Transactional 的每个属性都别放过2.1 propagation事务怎么传播路由就怎么走propagation是事务传播行为它解决的是“当前方法被一个已经开启事务的方法调用时该怎么办”的问题。这是Transactional里最容易配置错、也最容易引发线上事故的参数。默认值是Propagation.REQUIRED意思是如果外层有事务就直接加入外层事务如果外层没有事务就自己新建一个。绝大多数场景用默认值就够了。转账方法 A 调用扣款方法 B、加款方法 C三个方法都标记为 REQUIRED 时它们会全部落在同一个事务里任何一步失败整体回滚这正是我们想要的效果。真正需要小心的是Propagation.REQUIRES_NEW。它的行为是不管外层有没有事务都挂起外层事务新建一个独立事务。这个参数在“内部操作即使外部失败也必须成功”的场景里非常好用。我举一个真实案例订单处理失败时主事务回滚了但希望把失败原因写入审计日志日志写入不能被回滚拖累。把审计日志的写入方法标记为 REQUIRES_NEW就满足了需求。还有几个用得少的传播级别也简单带一下。NESTED是基于保存点Savepoint的嵌套事务外层回滚时内层也会回滚但内层可以先于外层独立回滚JDBC 场景下由DataSourceTransactionManager支持。MANDATORY要求外层必须已有事务否则抛异常NEVER正好相反要求外层绝对不能有事务NOT_SUPPORTED会让方法以非事务方式执行并挂起外层事务SUPPORTS则是可有可无外层有就加入没有就不开。这几个后面接触得少但你至少要知道它们的存在看到别人代码里用了不要懵。2.2 isolation隔离级别与“读”出来的各种问题isolation用来控制事务的隔离级别默认值是Isolation.DEFAULT代表沿用数据库自身的默认隔离级别。MySQL InnoDB 的默认隔离级别是REPEATABLE_READPostgreSQL 和 Oracle 默认是READ_COMMITTED。没有正确的隔离级别并发下会出现三种经典问题。第一个是脏读事务 A 读到事务 B 未提交的数据B 回滚后 A 读到的就是废数据。第二个是不可重复读事务 A 两次读同一行中间事务 B 提交了对这行的修改A 两次读到的结果不一样。第三个是幻读事务 A 按条件查一批数据期间事务 B 插入了符合条件的新数据A 再次查询时多出了原本不存在的行。隔离级别解决这些问题的关系大致是这样READ_UNCOMMITTED允许脏读并发最高但数据可信度最差基本不会在生产环境用READ_COMMITTED解决脏读但可能不可重复读REPEATABLE_READ解决不可重复读MySQL 在 InnoDB 下通过 next-key lock 也部分解决了幻读SERIALIZABLE全部解决但并发能力大幅下降。我给你的实操建议是不要轻易在注解里写死隔离级别优先让数据库兜底。如果你发现某个报表查询在并发场景下数据对不上先分析是脏读、不可重复读还是幻读再决定是否需要显式设置。绝大多数业务问题都能通过READ_COMMITTED或者默认级别解决贸然调高到SERIALIZABLE性能代价会立刻体现接口响应时间可能成倍增长。2.3 rollbackFor 与 noRollbackFor决定什么时候回滚这是Transactional参数里我私下认为最重要、也最容易踩坑的地方。Spring 的默认回滚规则是只有抛出RuntimeException或Error时才回滚遇到受检异常checked exception默认不回滚。为什么默认是这样因为 Spring 早期设计者认为受检异常往往代表业务上“可预期的失败”比如用户余额不足、订单状态非法这些场景可能业务上还希望继续执行或者做其他补偿不该让整个事务直接回滚。这个设计哲学放到今天看有争议因为很多团队的业务异常就定义为受检异常结果事务悄悄提交了数据就乱了。所以我的习惯很明确凡是涉及多条数据更新的 Service 方法一律写成Transactional(rollbackFor Exception.class)让所有异常都触发回滚。如果你希望某些特定异常不回滚再用noRollbackFor明确排除。这比自己默认依赖 RuntimeException 更稳妥因为你永远不知道团队里谁会在代码里抛一个新定义的受检异常。举一个常见的故障现场一个开户流程里先插入用户主表再插入用户扩展表扩展表插入时抛了一个自定义的BizException而这个异常继承自Exception而不是RuntimeException。结果就是用户主表数据留在库里事务没有回滚第二天用户反馈“我明明开通失败了为什么手机号已经被注册了”排查半天才发现是回滚配置的锅。2.4 timeout 与 readOnly两个性价比很高的性能参数timeout指定事务允许执行的最大秒数超过这个时间会抛出TransactionTimedOutException并触发回滚。默认值是 -1代表使用底层事务基础设施的默认超时时间即无超时限制。这个参数在外部接口调用缓慢、数据库锁等待严重的场景下很有价值。我曾经在一个对账接口上栽过跟头事务里同步调用了第三方渠道的接口渠道响应超时事务一直占着数据库连接最后连接池被耗尽整个服务瘫痪。后来在方法上加了timeout 5虽然渠道慢仍然会导致那笔业务失败但至少不会拖垮整个连接池。readOnly默认是 false。设为 true 时Spring 会把事务标记为只读对某些数据库和 ORM 框架可以做额外优化比如 Hibernate 会跳过脏检查同时它也是一个强制性的防呆如果有人在这个事务里误写了数据某些数据库会直接报错。需要强调的是它更多是一个提示和约束并不是所有数据库都会真正执行只读限制。我在团队里有个约定纯查询类方法如果能接受“读在事务里的一致性快照”就加上readOnly true顺手还能防止误操作写入。2.5 一张表收齐全部属性我常跟团队同学说把下面这张表存下来配置事务之前先对一眼比临时翻文档快得多。属性可选值默认值作用常用建议propagationREQUIRED、REQUIRES_NEW、NESTED、MANDATORY、NEVER、NOT_SUPPORTED、SUPPORTSREQUIRED决定事务如何加入或新建默认即可独立记录用 REQUIRES_NEWisolationDEFAULT、READ_UNCOMMITTED、READ_COMMITTED、REPEATABLE_READ、SERIALIZABLEDEFAULT控制并发读写隔离程度优先 DEFAULT避免滥用高隔离级别rollbackFor指定的异常类数组RuntimeException、Error哪些异常触发回滚业务方法写 Exception.classnoRollbackFor指定的异常类数组无哪些异常不触发回滚明确排除不需要回滚的异常timeout秒数-1无限制事务最大执行时间涉及外部调用时务必设置readOnlytrue / falsefalse标记只读事务优化并防呆纯查询方法可设 true3. 跑一个完整的转账事务案例3.1 准备依赖和数据库表观察一下不如实操一遍。我用一个经典的转账案例从账户 A 扣钱往账户 B 加钱中间任何一步失败扣掉的钱必须退回去。项目基于 Spring Boot先引入基础依赖这里我用 JdbcTemplate 来演示你可以根据自己团队的情况换成 MyBatis 或 JPA事务机制是通用的。dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-jdbc/artifactId /dependency dependency groupIdcom.mysql/groupId artifactIdmysql-connector-j/artifactId scoperuntime/scope /dependency然后在application.yml里配数据源。注意 MySQL 8 的驱动类名是com.mysql.cj.jdbc.Driver很多老项目还在用旧的com.mysql.jdbc.Driver新驱动下会直接报错。spring: datasource: url: jdbc:mysql://localhost:3306/demo?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/Shanghai username: root password: 123456 driver-class-name: com.mysql.cj.jdbc.Driver准备一张最简单的账户表两个字段就够了账户 ID、账户余额。如果你要演示更完整的场景可以再加一个唯一标识字段但对理解事务来说下面这张表足够。CREATE TABLE account ( id BIGINT PRIMARY KEY AUTO_INCREMENT, user_name VARCHAR(50) NOT NULL, balance DECIMAL(10, 2) NOT NULL DEFAULT 0.00 ); INSERT INTO account (user_name, balance) VALUES (张三, 1000.00); INSERT INTO account (user_name, balance) VALUES (李四, 500.00);3.2 编写 DAO 与 Service先写一个 DAO 类负责访问数据库。这里我故意只暴露扣款和查余额的方法加款逻辑放在 Service 的事务方法里使用另一个 DAO 方法方便待会儿演示回滚。Repository public class AccountDao { private final JdbcTemplate jdbcTemplate; public AccountDao(JdbcTemplate jdbcTemplate) { this.jdbcTemplate jdbcTemplate; } public BigDecimal getBalance(Long id) { ListBigDecimal results jdbcTemplate.query( SELECT balance FROM account WHERE id ?, (rs, rowNum) - rs.getBigDecimal(balance), id); return results.isEmpty() ? null : results.get(0); } public void decreaseBalance(Long id, BigDecimal amount) { jdbcTemplate.update(UPDATE account SET balance balance - ? WHERE id ?, amount, id); } public void increaseBalance(Long id, BigDecimal amount) { jdbcTemplate.update(UPDATE account SET balance balance ? WHERE id ?, amount, id); } }接下来是核心的 Service。转账方法上我加了Transactional(rollbackFor Exception.class)并且在扣款之后模拟了一次目标账户不存在的异常。记住这个顺序等会儿你会看到回滚效果。Service public class TransferService { private final AccountDao accountDao; public TransferService(AccountDao accountDao) { this.accountDao accountDao; } Transactional(rollbackFor Exception.class) public void transfer(Long fromId, Long toId, BigDecimal amount) { BigDecimal fromBalance accountDao.getBalance(fromId); if (fromBalance null || fromBalance.compareTo(amount) 0) { throw new IllegalArgumentException(余额不足); } accountDao.decreaseBalance(fromId, amount); // 模拟目标账户不存在导致第二笔操作失败 BigDecimal toBalance accountDao.getBalance(toId); if (toBalance null) { throw new IllegalArgumentException(目标账户不存在); } accountDao.increaseBalance(toId, amount); } }3.3 验证回滚加一个“意外”看看效果写个测试入口故意传入一个不存在的目标账户 ID然后分别打印操作前后的余额。比如张三账户转账 200 元给一个 ID 为 999 的不存在账户。执行之后你会看到张三的扣款 SQL 已经执行了但因为方法最终抛出了IllegalArgumentException整个事务回滚张三的余额仍然是 1000.00。没有Transactional的时候这个测试会留下一个严重的数据错误钱扣了但没人收到。我还做过一个对比测试把Transactional(rollbackFor Exception.class)拿掉改为默认回滚规则然后把IllegalArgumentException换成一个自定义的受检异常。结果非常直观异常抛出了但扣款操作被“提交”了张三账户凭空少了 200 块。这个实验我强烈建议你亲手做一次比看十篇文档都记得牢。如果要在转账之外记录审计日志而且希望日志在转账失败后仍然保留就能用到Propagation.REQUIRES_NEW。把日志写入抽到单独的AuditLogService里方法上加Transactional(propagation Propagation.REQUIRES_NEW)这样无论主事务回滚与否审计记录都会独立提交。注意这里必须单独用一个 bean如果在同一个类里用this.recordLog()调用REQUIRES_NEW 是不会生效的原因下一节展开讲。4. 事务失效的经典场景每一个我都踩过4.1 同一个类里自己调自己这是江湖上最经典的事务失效场景原理一句话就能说透Transactional是靠 Spring AOP 代理生效的外部调用走的都是动态代理但同一个类内部的this.method()调用走的是原生对象代理根本拦不到。看下面这段代码Service public class OrderService { public void createOrderAndUpdateStock() { this.createOrder(); // 内部调用事务不生效 this.updateStock(); // 内部调用事务不生效 } Transactional(rollbackFor Exception.class) public void createOrder() { ... } Transactional(rollbackFor Exception.class) public void updateStock() { ... } }当你在createOrderAndUpdateStock()里调用this.createOrder()时相当于绕过了 Spring 生成的代理对象直接进入目标类的真实方法事务根本不会被拦截。结果就是两个操作分别停留在各自的没有事务的状态中间任何一个失败已经执行的 SQL 都不会回滚。解决办法有三个按推荐度排序第一把需要事务的方法拆到另一个独立的 Service bean 里注入后通过代理调用第二在类里注入自身代理Autowired private OrderService self;然后通过self.createOrder()调用第三使用AopContext.currentProxy()但这要求额外开启exposeProxy环境配置复杂一点我一般只在不得已的时候用。还有一个隐藏点服务启动时如果有自调用逻辑哪怕外层方法本身没有事务内层方法的事务也照样失效。我排查过一个定时任务的问题方法内部循环调用同类的Transactional方法导致每笔操作都是独立非事务执行中间哪条失败之前的数据全都不回滚。这类问题日志里几乎不会有异常错误只能靠代码 review 盯出来。4.2 异常被 try-catch 吞掉这个场景我见过太多。代码里加了个 try-catch把异常捕获后记了一下日志然后方法正常返回结果事务提交了数据却是不完整的。原因很简单事务是否回滚取决于异常有没有传到 Spring 的拦截器手里。你 catch 住了异常就“到此为止”通知逻辑只知道方法执行完了自然按提交处理。正确的做法要看你真正的意图。如果确实需要捕获异常做二次处理那捕获之后必须重新抛出原异常或者抛出新的RuntimeException让事务管理器能感知到失败。如果只是想把异常补偿给某个日志表建议使用上一节提到的独立事务的日志 Service主事务该失败就失败日志通过 REQUIRES_NEW 单独提交。我踩过一次特别隐蔽的坑在一个批量导入接口里循环调用了事务方法每一条数据都包了 try-catch想着失败了就继续导入下一条。结果每一条失败的数据对应的半截更新全被提交了最终库里出现了一堆“主表有、明细缺失”的问题记录。后来改成每批事务 失败记录单独落库问题才彻底了结。4.3 方法不是 public或者类没交给 SpringSpring 官方文档明确写着Transactional应该只应用于 public 方法而且要通过 Spring 管理的 bean 来调用。如果你把注解放在 private 方法上Spring 会直接忽略连报错都没有。如果你放在 protected 或包内方法上在基于 CGLIB 代理的某些场景下可能有点效果但行为不确定生产环境千万别赌。还有一种更隐蔽的情况方法明明是 public 的注解也写了但类本身没有被 Spring 扫描到。常见的诱因是包的扫描路径没覆盖到或者类被 new 出来而不是通过 IoC 容器注入。如果是你自己new OrderService()来调方法那就算把所有注解都复制上去也没用因为根本没有代理介入。我建议你养成一个检查习惯看到Transactional的时候先问自己三个问题——这个类是 Spring 管理的 bean 吗方法是不是 public方法是不是通过代理调用进来的只要有一个答案是否定的事务就该出问题了。4.4 事务不生效的 5 步排查清单如果你发现事务没有达到预期的回滚效果别慌按下面这个顺序去查基本不会漏。步骤检查项大概率原因1类是否被 Spring 管理漏配 Service、包扫描不对2方法是否为 publicprivate 方法注解被无视3是否同类自调用内部调用绕过代理4异常是否被 try-catch 吞掉异常没传给拦截器5回滚配置是否覆盖异常默认只回滚 RuntimeException受检异常需配 rollbackFor这五步排查下来百分之九十的事务失效问题都能定位。剩下百分之十大概率是事务管理器没配好、多数据源场景下事务管理器选错了这种环境级问题等下一个小节我会专门讲。5. 生产环境里的避坑经验5.1 大事务是性能杀手怎么拆分事务不是包得越大越好。一个事务内部如果塞进了大量的 SQL、外部接口调用、甚至耗时的计算逻辑数据库连接就会被占住很久行锁也会被持有更长时间并发能力肉眼可见地往下掉。生产环境里很多“请求超时”、“死锁变多”的问题到最后都指向那几个被塞得满满当当的大事务。我的拆事务原则是这样的数据库操作部分才需要事务保护外部调用、文件读写、消息发送这些尽量挪到事务边界之外。如果非得在事务内外做某种协同可以先把业务数据写进事务提交后再异步发消息或者调用外部系统如果外部调用失败需要补偿再用本地消息表或定时任务去重试。要拆分一个已经存在的大事务最直接的方法是抽出多次小事务或者用 REQUIRES_NEW 把耗时的子操作隔离出去。如果条件允许我还会顺手设置一下事务的 timeout。因为没设 timeout 的事务一旦遇到锁等待或者慢 SQL 卡住会一直撑着不释放连接池很容易被拖垮。设一个合理的超时时间至少能把故障的影响面控制在单个请求内。5.2 跨线程调用事务不会跟着走Transactional的事务上下文是通过 ThreadLocal 传递的严格绑定在当前线程上。你用CompletableFuture、new Thread或者Async开一个子线程去执行带事务注解的方法子线程里的事务上下文和主线程完全是两套主线程的回滚不会带走子线程提交的数据。我处理过一个真实事故主流程里更新了订单状态并开启事务再异步去发通知短信短信子线程里也有自己的事务操作。主流程失败回滚时订单状态正常回退了但短信记录居然已经提交了用户收到了“订单已取消”的提示订单其实还挂着。类似这种问题排查起来特别难受因为事务本身没有报错只能靠链路日志逐步定位。解决方案取决于业务目标。如果异步任务需要“随主事务一起成功或一起失败”那就不该真正异步化应该同步调用或者用消息事务保证最终一致。如果异步任务与主流程成功与否无关那确实可以异步执行但要单独设计它自己的事务边界和失败补偿别指望 Spring 帮你把 ThreadLocal 传过去。记住这句结论跨线程事务就不可靠了。5.3 多数据源场景下 Transactional 的边界一个项目配置了多个数据源比如主库和报表库你给一个方法加Transactional它只会绑定在默认的PlatformTransactionManager上。默认事务管理器处理的是主数据源的事务另外那个数据源的写入并不受这个注解管辖。很多人会想当然以为一个事务注解能管住所有配置的数据源这就直接掉进坑里了。如果你的事务管理器有多个可以在注解上显式指定例如Transactional(transactionManager reportTransactionManager)。但说实话这只适用于单个数据源内的事务控制。跨数据源的多个写操作想保证原子性靠本地注解是无解的必须引入分布式事务方案。这里我不建议一上来就上分布式事务组件成本很高而且很多业务其实可以接受最终一致性。你可以先把这类跨库写操作拆成多个本地事务配合消息队列和补偿任务去实现同步和兜底。大多数企业项目的报表数据、统计数据和业务主数据之间本来就是允许短时间不一致的没有必要为了强一致付出那么大的复杂度。5.4 用日志确认事务是否真的开了遇到事务行为诡异的时候第一件事不是翻代码而是打开日志确认事务到底开没开。Spring 的TransactionInterceptor会输出很清晰的事务开始和结束日志仓库里把日志级别调一下就行。logging: level: org.springframework.transaction.interceptor: DEBUG org.springframework.jdbc.datasource.DataSourceTransactionManager: DEBUG调完日志级别再去触发你怀疑有问题的方法会看到类似Getting transaction for [...]、Completing transaction for [...]的日志。如果方法被调用但没有任何 Getting transaction 日志基本可以断定代理没生效如果看到 Completing transaction 是 rollback 还是 commit也能直接判断异常有没有正确传导到回滚逻辑里。这条日志流是我排查所有事务问题时第一步必然做的事比盯着代码猜有效得多。再分享一个小技巧如果觉得日志太啰嗦可以在关键的 Service 方法里临时加一行断点日志打印当前事务名或者用TransactionSynchronizationManager.isActualTransactionActive()在代码里动态判断当前是否真的处于一个活动事务里。这个判断方法加在 try-catch 里非常有用能帮你精确确认事务边界到底从哪一行开始生效。最后再聊一点我个人的体会配置Transactional这件事代码量很小但背后的设计陷阱一点都不少。我见过太多团队在事务问题上反复踩同一批坑根源多半是只把它当成“一个注解”而不是“一套机制”。如果你愿意花半小时把我上面说的自调用、异常吞掉、回滚规则这三个点亲手验证一遍后续在事务上的排障时间至少能省下一大半。
