Spring事务传播行为详解
2025年Java面试宝典已上传网盘，需要突击面试的小伙伴可以自取：
点击下载（提取码：9b3g）
作为Java程序员绕不开的面试考点，Spring事务传播行为既考验框架理解深度，又是设计分布式事务的关键。今天咱们通过高频面试题拆解这个知识点，帮你建立系统性认知。
什么是事务传播行为？
简单来说，事务传播行为定义了多个事务方法相互调用时，事务应该如何传递。比如方法A调用方法B，B是否需要加入A的事务？还是自己独立开新事务？这就是由传播行为决定的。
Spring提供了7种传播行为，其中最常问的是前4种：REQUIRED、SUPPORTS、REQUIRES_NEW、NESTED。建议先记这四种的差异，其他类型在真实业务中较少用到。
高频面试问题拆解
问题1：REQUIRED和REQUIRES_NEW有什么区别？
这是传播行为的必考题！回答时可以分三层递进：
- 事务存在时：REQUIRED会加入当前事务，REQUIRES_NEW会挂起原事务并创建新事务
- 事务不存在时：两者都会新建事务
- 异常回滚范围：REQUIRED共用事务，任意方法异常都会整体回滚；REQUIRES_NEW独立事务，只有自己的异常会触发回滚
举个实际场景：订单服务调用积分服务。如果希望积分服务失败不影响主订单，就该用REQUIRES_NEW
问题2：NESTED和REQUIRES_NEW有什么异同？
这个问题的难点在于两者都会创建新事务，但回滚机制不同：
- 保存点机制：NESTED使用保存点实现嵌套事务，外部事务回滚会导致内部一起回滚
- 独立提交：REQUIRES_NEW是完全独立的事务，外部事务回滚不影响已提交的内部事务
- 数据库支持：NESTED需要JDBC3.0+且数据库支持保存点（比如MySQL的InnoDB引擎）
业务场景选择指南
传播行为的选择直接影响系统一致性，这里给出三个典型场景：
场景1：强一致性需求
使用默认的REQUIRED，保证多个操作处于同一事务中。例如银行转账：扣款和入账必须同时成功或失败
场景2：非核心业务解耦
使用REQUIRES_NEW，比如下单后发送短信。即使短信服务挂了，也不能让整个订单回滚
场景3：有条件回滚
使用NESTED，比如电商系统中的库存预扣。主事务失败时需要释放预扣库存，但已完成的预扣操作需要保留
避坑指南
- 慎用SUPPORTS，当方法不需要事务时，直接不声明事务更安全
- NEVER传播行为要慎用，它强制要求不能存在事务，容易引发意外异常
- 嵌套事务的性能损耗主要来自数据库保存点创建，高并发场景要评估影响
需要系统复习Spring事务知识的话，推荐通过面试鸭返利网获取最新面试题库，现在购买会员还能返利25元。以下是他们的优惠活动图：
常见误区纠正
- "事务传播行为是Spring特有的" → 错！这是对JTA规范的实现
- "REQUIRES_NEW一定比REQUIRED好" → 错！过度使用会导致事务膨胀
- "所有数据库都支持NESTED" → 错！要看具体数据库的保存点支持情况
掌握事务传播行为的关键是多画事务边界图，理解不同传播行为在方法调用时的状态变化。建议结合分布式事务场景做延伸思考，比如如何与Seata框架配合使用。
