Spring事务的1道面试题
每次聊起Spring事务,好像很熟悉,又好像很陌生。本篇通过一道面试题和一些实践,来拆解几个Spring事务的常见坑点。
原理
Spring事务的原理是:通过AOP切面的方式实现的,也就是通过代理模式去实现事务增强。
具体过程是:对包含@Transactional
注解的方法进行拦截,然后重写,重新在方法里加入异常回滚的逻辑。而且,每个线程都是独立管理自己的事务,相互隔离。
原理简单,使用起来也简单,也就是在方法上打上@Transactional
注解,然后事务就正常生效了。也很少有人去验证异常情况下是否能真正的回滚。
Spring事务让我熟悉的地方是哪哪看起来都简单,让我陌生的地方使用时的变种较多,有时候莫名其妙的不生效。
源码
以上原理的相关源码如下:
实践出真知
但是 [半支烟] 偶尔会在编码过程中发现有些场景下的事务是失效的,总有些情况让你想不到,总有一些坑点等你去跳。
[半支烟] 觉得验证事务的最好方式就是:记住基本原则 + 动手实践 。记住基本原则可以快速处理常规问题,动手实践可以验证偏门问题或者不确定的问题。
几种事务不生效的用法
如下是常见的几种Spring事务不生效的用法,有空的读者一定要牢记,对日常编码很有帮助,同时面试时也能说几句。
- private方法
Spring是通过AOP代理的方式实现事务增强的,但是private方法无法被代理,所以在private方法上打@Transactional
注解是不生效的。
- final、static修饰的方法
和private方法类似,final和static修饰的方法也无法被代理,所以@Transactional
注解也不生效。
因为,static是属于类方法,final修饰的方法无法被重写,自然也就无法植入事务增强代码。
- Bean对象没有被Spring托管
某个类一定要被Spring托管,那才能通过@Transactional
注解去增强事务。如果只有@Transactional
注解,而没有把类交给Spring托管,事务也是不生效的。类似如下情况:
// 此处没有@Service注解,此类不被spring托管,及时有@Transactional也不生效
public class UserService {
@Autowired
private UserMapper userMapper;
@Transactional
public final void createAndUpdateUser() {
createUser();
updateUserById();
}
public void createUser() {
User user = new User();
user.setId(2L);
user.setName("test2");
user.setEmail("test2" + "@test.com");
userMapper.insert(user);
System.out.println("create user");
}
public void updateUserById() {
User user = userMapper.findById(1L);
user.setName("admin1");
userMapper.update(user);
int i = 1 / 0; // 此处会抛出异常
System.out.println("update user");
}
}
- 异常被吞掉
如果在业务代码里,通过try......catch捕获了异常,同时又没有继续抛出异常时,Spring事务也是不生效的。
因为代理增强的逻辑就是要发现了异常,才能回滚事务。如果异常被方法本身吞掉了,则代理会认为没有异常,从而无法回滚。
- 非RuntimeException异常
Spring事务默认会回滚RuntimeException
及其子类,以及 Error
类型的异常。如果是其余异常,则不会回滚。源码处可见:
这种非RuntimeException异常场景下,需要做2个动作从而保证事务回滚。
- 捕获异常,然后抛出自定义异常。
- 自行在
@Transactional
注解中增加@Transactional(rollbackFor = XxxxxxxException.class)
属性。或者直接使用rollbackFor = Exception.class
,也就免去了第一步。
- 异步线程的场景
多个线程的场景下,只需要牢记每个线程只管理自己的事务即可。每个线程都有一个独立的事务上下文,存在ThreadLocal中,所以事务信息在不同线程之间是隔离的。
- 重灾区:在同一个类中调用本类的方法
这个失效场景,是最容易出错的,而且变种还多。在同一个类中调用本类的方法时,牢记以下2点,即可破局:
- 是否会开启事务依赖此类的第一个被外部调用的方法。如果此类的第一个被外部调用的方法有
@Transactional
注解,那事务生效。 - 调用自己内部方法时,采用的是
this.xxxMethod()
的方式,这种方式是不会走AOP代理的,所以被调用的内部方法的@Transactional
注解不生效。
如果确实需要调用内部方法,并且要事务生效的话,那只能将被调用的内部方法独立到新的类中,同时交给Spring管理。
一道面试题
以上关于事务不生效的用法都比较好记,只有在同一个类中调用本类的方法
场景下存在多种变种。具体请看这道面试题。请问以下createAndUpdateUser
方法的事务生效吗?
@Service
public class UserService {
@Autowired
private UserMapper userMapper;
@Transactional
public final void createAndUpdateUser() { //注意这里有final修饰
createUser();
updateUserById();
}
@Transactional
public void createUser() {
User user = new User();
user.setId(2L);
user.setName("test2");
user.setEmail("test2" + "@test.com");
userMapper.insert(user);
System.out.println("create user");
}
@Transactional(rollbackFor = Exception.class)
public void updateUserById() {
User user = userMapper.findById(1L);
user.setName("admin1");
userMapper.update(user);
int i = 1 / 0; // 此处会抛出异常
System.out.println("update user");
}
}
如果按照重灾区:在同一个类中调用本类的方法
里提到的2个原则,则事务全部生效。
如果按照final、static修饰的方法
里提到的原则,则事务全部不生效。
那结果如何呢?结果是以上方法的事务全部生效。
为什么呢?这里在补充一个原则:final修饰的方法如果带上@Transactional注解,事务情况按照被调用的方法自身的事务托管情况而定。
因为以上代码中的createUser
方法和updateUserById
方法,都有@Transactional
注解,所以都生效。
这种特殊情况也实在是让人瞠目,不过只需要牢记以上几种不生效的用法即可,谁没事儿写这种@Transactional
+ final
的代码呢?除了面试会问......
总结
本篇主要聊了几种事务不生效的用户,有兴趣的读者可以记一下。同时,还出了一道特殊场景的面试题,供读者自行实践。希望对你有帮助!
本篇完结!欢迎 关注、加V(yclxiao)交流、全网可搜(程序员半支烟)
原文链接: https://mp.weixin.qq.com/s/V5KpVk0kDhc9vWctOy7X9A
半支烟推出《开发者AI加持》,一个AI应用开发专栏,旨在助力开发者多一技傍身。还有 1V1技术咨询 ,扫清职业发展和技术道路上的障碍,加V(yclxiao)咨询。