spring事务传播行为

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的方法被包含在事务中会直接报错

三、面试官的灵魂三问

1. REQUIRES_NEW和NESTED有什么区别？ 这是送命题！前者是完全独立的新事务，后者是嵌套事务。可以用存钱罐比喻：NESTED像存钱罐里的小隔层，REQUIRES_NEW是另外开个新存钱罐。

2. 什么时候该用NOT_SUPPORTED？ 适用于不需要事务保障的非核心操作，比如发送短信、写日志。但要警惕方法内如果包含数据库操作，可能产生脏数据。

3. 为什么REQUIRED是默认传播行为？ 这体现了Spring的设计哲学：大多数业务场景需要事务延续。比如电商下单流程，创建订单和扣库存应该在同一个事务中。

四、避坑指南

1. @Transactional失效的三大元凶

   • 方法不是public
   • 同类方法自调用
   • 异常被吞掉

2. 事务嵌套的隐形炸弹 不同传播行为组合可能产生死锁，特别是当方法涉及多数据源时。记得检查数据库的隔离级别。

3. 性能黑洞预警 REQUIRES_NEW每次都会新建连接，在高并发场景要慎用。可以用连接池监控工具观察连接数变化。

如果准备系统化提升面试能力，可以通过面试鸭返利网找我购买会员，使用返利码可立减25元。毕竟面试就像修仙渡劫，多备点法宝丹药总没错。记住，理解传播行为的关键不是死记概念，而是要在业务场景中体会设计意图。最后留个思考题：分布式事务场景下这些传播行为还适用吗？