Spring 事务的一道面试题

每次聊起 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 个动作从而保证事务回滚。

1. 捕获异常，然后抛出自定义异常。

2. 自行在@Transactional注解中增加@Transactional(rollbackFor = XxxxxxxException.class)属性。或者直接使用rollbackFor = Exception.class，也就免去了第一步。

• 异步线程的场景

多个线程的场景下，只需要牢记每个线程只管理自己的事务即可。每个线程都有一个独立的事务上下文，存在 ThreadLocal 中，所以事务信息在不同线程之间是隔离的。

• 重灾区：在同一个类中调用本类的方法

这个失效场景，是最容易出错的，而且变种还多。在同一个类中调用本类的方法时，牢记以下 2 点，即可破局：

1. 是否会开启事务依赖此类的第一个被外部调用的方法。如果此类的第一个被外部调用的方法有@Transactional注解，那事务生效。

2. 调用自己内部方法时，采用的是this.xxxMethod()的方式，这种方式是不会走 AOP 代理的，所以被调用的内部方法的@Transactional注解不生效。

如果确实需要调用内部方法，并且要事务生效的话，那只能将被调用的内部方法独立到新的类中，同时交给 Spring 管理。

一道面试题

以上关于事务不生效的用法都比较好记，只有在同一个类中调用本类的方法场景下存在多种变种。具体请看这道面试题。请问以下createAndUpdateUser方法的事务生效吗？

@Servicepublic 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的代码呢？除了面试会问......

总结

本篇主要聊了几种事务不生效的用户，有兴趣的读者可以记一下。同时，还出了一道特殊场景的面试题，供读者自行实践。希望对你有帮助！

文章转载自：程序员半支烟

原文链接：https://www.cnblogs.com/mangod/p/18456140

体验地址：http://www.jnpfsoft.com/?from=infoq