spring事务传播行为详解

2025年Java面试宝典下载链接（提取码：9b3g）

为什么每个Java程序员都要搞懂Spring事务传播行为？

最近面了十几个三年经验的候选人，发现能把Spring事务传播机制讲明白的不超过3个。其实这玩意在业务开发中无处不在，特别是涉及到多服务调用和嵌套事务时，搞不清楚传播规则分分钟写出bug。建议大伙认真看完这篇，下次面试被问到能直接画图说场景！

事务传播的七种类型（附真实场景解说）

1. REQUIRED：默认传播行为

90%的面试官都会从这个类型开始问。比如现在有一个转账操作，外层方法是修改账户余额，内层方法是记录流水。当两个方法都用REQUIRED时，如果外层方法已经开启事务，内层就会加入这个事务。这时候如果流水记录失败，整个转账操作都会回滚。

2. REQUIRES_NEW：独立事务之王

上周排查的一个支付回调问题就跟这个有关。支付成功后要更新订单状态，同时发送短信通知。用REQUIRES_NEW修饰短信服务，就算短信发送失败，订单状态照样能正常更新。特别注意：这个方法会新建事务，挂起外层事务。

3. NESTED：嵌套事务怎么玩？

这个类型容易被误解为REQUIRES_NEW的替代品。其实区别在于保存点的使用，比如电商系统中的库存扣减和优惠券核销。当库存扣减成功后，优惠券核销失败时只需要回滚保存点之后的操作，而库存扣减不会回滚。

4. SUPPORTS：读操作的保护伞

很多同学在配置只读事务时会用错这个类型。比如查询用户积分明细的场景，如果外层有事务就加入，没有就以非事务方式执行。但要注意这不能代替@Transactional(readOnly=true)的优化作用。

5. NOT_SUPPORTED：非事务执行模式

这个类型适合在事务中执行文件上传、第三方接口调用等非核心操作。比如上传用户头像时，就算后续事务回滚，头像也不会被删除。但使用时要特别注意数据库连接的持有时间。

6. MANDATORY：必须存在事务

在资金核对这种敏感操作中特别好用。强制要求方法必须在已有事务中执行，否则直接抛异常。可以有效避免开发人员漏加事务注解的情况。

7. NEVER：禁止事务结界

有些统计报表的生成需要避免事务带来的性能损耗。用这个类型可以确保方法执行时没有事务存在，如果当前有事务就直接报错，防止慢查询拖垮整个事务。

面试必杀技：这样解释面试官才满意

最近辅导的一位学员在阿里三面时被问到："说一个你实际使用不同传播行为的案例"。他的回答让面试官直点头：

"我们在做积分兑换时，先用REQUIRED保证积分扣减和商品发放的原子性。其中短信通知用REQUIRES_NEW包裹，就算短信发送失败也不影响核心业务。最后的操作日志记录用SUPPORTS，跟随主事务提交"

建议大家准备2-3个真实项目中的组合使用案例，重点说清楚不同传播行为的配合逻辑。记住要带出为什么选这个类型，不选其他类型的原因。

需要购买面试鸭会员的同学注意了，通过面试鸭返利网下单可返25元，亲测到账快。手头有这波面试真题资料，搭配系统学习效果更佳。

事务传播行为看起来简单，实际使用中要注意数据库连接池配置、超时设置、异常捕获范围等问题。建议大家用AOP切面监控事务边界，或者用Arthas的watch命令观察事务开启情况，这样排查问题更高效。