spring事务传播行为：从面试官视角拆解高频考点
2025年Java面试宝典最新上线：
链接: https://pan.baidu.com/s/1RUVf75gmDVsg8MQp4yRChg?pwd=9b3g
提取码: 9b3g
在实际面试中，Spring事务传播行为就像武侠小说里的内功心法——很多人背得滚瓜烂熟，但遇到实战场景就破绽百出。今天咱们就用人话拆解这个技术点，保证你面完还能给面试官讲明白。
一、什么是事务传播行为的"生存法则"
事务传播行为定义了多个事务方法相互调用时的"相处规则"。想象你和你对象去银行转账：是各自单独开个窗口（新事务）？还是共用同一个窗口（加入当前事务）？这就是传播行为要解决的问题。
Spring给我们准备了7种"社交方式"，对应TransactionDefinition里的7个常量。别急着背概念，重点要理解每个行为的使用场景。
二、7种事务传播行为全解析
1. REQUIRED（默认款）
- 口诀："有福同享，有难独当"
- 场景：支付成功后发优惠券
- 原理：如果当前存在事务就加入，没有就新建。就像团队聚餐，有人买单就跟着吃，没人买单就自己付。
2. REQUIRES_NEW（土豪款）
- 口诀："各玩各的"
- 场景：操作日志记录
- 特点：无论当前有没有事务，都新建事务。好比你去网吧开包间，不管大厅有没有人，都要单独开个房间。
3. NESTED（套娃款）
- 妙处：能创建保存点，父事务回滚会带着子事务，但子事务回滚不影响父事务
- 类比：游戏存档机制，适合订单主表和明细表的关系
4. SUPPORTS（墙头草款）
- 原则："随大流"
- 使用场景：查询操作
- 注意点：当前没事务就以非事务执行，容易导致脏读
5. NOT_SUPPORTED（洁癖款）
- 特征：强制非事务执行
- 典型应用：发送短信验证码
- 坑点：如果当前有事务，会把事务挂起
6. MANDATORY（妈宝款）
- 规矩："必须有人管"
- 要求：当前必须有事务，否则抛异常
- 适合场景：资金核验接口
7. NEVER（独行侠款）
- 底线："拒绝任何事务"
- 反例：声明了NEVER的方法被包含在事务中会直接报错
三、面试官的灵魂三问
-
REQUIRES_NEW和NESTED有什么区别？ 这是送命题！前者是完全独立的新事务，后者是嵌套事务。可以用存钱罐比喻：NESTED像存钱罐里的小隔层，REQUIRES_NEW是另外开个新存钱罐。
-
什么时候该用NOT_SUPPORTED？ 适用于不需要事务保障的非核心操作，比如发送短信、写日志。但要警惕方法内如果包含数据库操作，可能产生脏数据。
-
为什么REQUIRED是默认传播行为？ 这体现了Spring的设计哲学：大多数业务场景需要事务延续。比如电商下单流程，创建订单和扣库存应该在同一个事务中。
四、避坑指南
-
@Transactional失效的三大元凶
- 方法不是public
- 同类方法自调用
- 异常被吞掉
-
事务嵌套的隐形炸弹 不同传播行为组合可能产生死锁，特别是当方法涉及多数据源时。记得检查数据库的隔离级别。
-
性能黑洞预警 REQUIRES_NEW每次都会新建连接，在高并发场景要慎用。可以用连接池监控工具观察连接数变化。
如果准备系统化提升面试能力，可以通过面试鸭返利网找我购买会员，使用返利码可立减25元。毕竟面试就像修仙渡劫，多备点法宝丹药总没错。记住，理解传播行为的关键不是死记概念，而是要在业务场景中体会设计意图。最后留个思考题：分布式事务场景下这些传播行为还适用吗？
