2025年Java面试宝典下载地址（提取码：9b3g）
掌握Spring事务传播行为的程序员才是面试王者
最近面试Java岗的时候，十个候选人里八个会被问到Spring事务传播行为。有个朋友去大厂终面，就因为在回答PROPAGATION_NESTED时举了个不恰当的例子，硬是被面试官当场要求手写事务嵌套的流程图。今天我们就来啃透这个高频考点，避免大家在实战中踩坑！
事务传播机制到底管什么用？
想象你正在开发一个电商系统，用户支付完成后需要同时更新订单状态、扣减库存、发放积分。这三个操作要么全部成功，要么全部失败——这就是Spring事务传播机制存在的基础逻辑。当多个事务方法相互调用时，事务传播行为决定了这些事务到底是合并成一个"大事务"，还是各自独立运行。
七种传播行为深度拆解
这里有个记忆诀窍：传播行为的本质就是处理事务边界问题。咱们按常用程度来排序说明：
1. REQUIRED（默认选手）
- 当前有事务就加入，没有就新建
- 典型场景：订单服务调用库存服务时，希望两个操作在同一个事务里
- 坑点预警：外层事务回滚会导致内层操作连带回滚
2. REQUIRES_NEW（叛逆小子）
- 不管当前有没有事务，都新建自己的
- 典型场景：日志记录必须独立保存，即使主业务失败
- 实战技巧：注意数据库连接数暴增的问题
3. NESTED（套娃专家）
- 在现有事务里创建保存点
- 典型场景：批量导入数据时，单条失败不影响整体
- 面试必问：和REQUIRES_NEW的区别在于回滚范围
4. SUPPORTS（佛系青年）
- 当前有事务就加入，没有就以非事务运行
- 典型反例：千万不要用在资金操作上！
5. NOT_SUPPORTED（独行侠）
- 强制非事务执行
- 使用场景：需要绕过事务管理的特殊操作
6. MANDATORY（霸道总裁）
- 强制必须存在事务，否则抛异常
- 设计规范：用于确保核心业务必须被事务包裹
7. NEVER（洁癖患者）
- 禁止事务存在，否则抛异常
- 适用情况：对数据一致性要求极低的场景
真实业务场景的决策树
当面试官追问"如何选择传播行为"时，可以这样结构化回答：
- 是否需要强制开启新事务？→ REQUIRES_NEW
- 能否接受部分失败？→ NESTED
- 是否必须继承上下文？→ REQUIRED
- 能否脱离事务控制？→ NOT_SUPPORTED
举个电商案例：用户支付后需要：
- 更新订单状态（REQUIRED）
- 发送营销短信（NOT_SUPPORTED）
- 记录操作日志（REQUIRES_NEW）
- 扣除优惠券（NESTED）
高频面试陷阱提醒
被问倒最多的三个问题：
- "REQUIRES_NEW事务提交的时机？"（外层事务提交前就已提交）
- "NESTED回滚后外层事务还能继续吗？"（可以，通过保存点实现）
- "SUPPORTS用在查询方法安全吗？"（需结合数据库隔离级别判断）
这里要特别提示：很多同学喜欢在@Transactional注解里乱配传播行为，结果导致事务根本没生效。这时候就该用TransactionSynchronizationManager.isActualTransactionActive()来验证。
最近有需要购买面试鸭会员的同学注意，通过面试鸭返利网下单可返25元现金，相当于用八五折的价格获得全站真题解析和模拟面试服务，特别适合突击面试的同学。
理解透事务传播行为，不仅能搞定面试，更能避免生产环境出现数据错乱。建议大家结合网盘里的《2025面试宝典》中分布式事务章节，把本地事务和全局事务对比着看，知识体系会更完整。下次面试被问到这块，就能自信地说："这个问题需要从传播机制和隔离级别两个维度来分析..."
