【Java面试篇】Spring中@Transactional注解事务失效的常见场景

@Transactional注解的失效场景

☁️前言

最初学习Spring时，B站的杨老师就说过“在工作中不要过于依赖@Transactional注解实现事务，我们不仅要掌握注解实现事务，还需要掌握通过配置文件实现事务”，当时他没有明确说为什么，现在我应该是大致了解了，因为@Transactional注解对于新手而言是存在很多坑的，在很多情况下@Transactional注解都会失效，现在就让我们来详细学习哪些情况下@Transactional注解实现的事务会失效吧😄。

PS：关于如何通过配置文件实现事务请参考Spring学习笔记

🍀前置知识

• 事务：指访问并可能更新数据库中各种数据项的一个程序执行单元(unit)。可以理解事务就是一段代码块或者一行SQL，这段代码或这行SQL会更新数据库，事务具有基本的ACID特性，以此保障数据的安全性。

• 事务管理：由事务管理器¹、恢复管理器²、锁管理器³、死锁管理器⁴、缓存管理器⁵构成

• 事务管理的作用：管理事务相关的资源；更容易处理复杂的事务；简化事务相关的操作，让程序员更关注业务

• Spring中提供了两种事务管理机制：

  • 编程式事务：是指在代码中手动的管理事务的提交、回滚等操作，代码侵入性比较强。（Spring提供了TransactionTemplate模板，利用该模板我们可以通过编程的方式实现事务管理，而无需关注资源获取、复用、释放、事务同步及异常处理等操作。相对于声明式事务来说，这种方式相对麻烦一些，但是好在更为灵活，我们可以将事务管理的范围控制的更为精确）
  • 声明式事务：基于AOP面向切面的，它将具体业务与事务处理部分解耦，代码侵入性很低。而声明式事务有两种方式实现，方式一是基于@Transaction注解实现，方式二是基于XML实现。（Spring事务管理的亮点在于声明式事务管理，它允许我们通过声明的方式，在IoC配置中指定事务的边界和事务属性，Spring会自动在指定的事务边界上应用事务属性。相对于编程式事务来说，这种方式十分的方便，只需要在需要做事务管理的方法上，增加@Transactional注解，以声明事务特征即可）

  大多数 Spring 框架的用户选择声明式事务管理，因为它对应用代码的影响最小， 因此更符合一个无侵入的轻量级容器的思想。声明式事务管理要优于编程式事务 管理，虽然比编程式事务管理（这种方式允许你通过代码控制事务）少了一点灵 活性。

• @Transactional：可以作用在接口、类、方法

  • 作用于接口：不推荐这种使用方法，因为一旦标注在Interface上并且配置了Spring AOP 使用CGLib动态代理，将会导致@Transactional注解失效
  • 作用于类：当把@Transactional 注解放在类上时，代表这个类所有公共（public）非静态（static）的方法都将启用事务功能，且都会被 Spring 的事务管理器进行管理
  • 作用于方法：当把@Transactional配置在方法上，该方法被当成一个独立的事务，且被事务管理器管理。当类配置了@Transactional，方法也配置了@Transactional，此时方法的事务会覆盖类的事务配置信息

• @Transactional的属性

  

  • propagation属性

    propagation 代表事务的传播行为，默认值为 Propagation.REQUIRED，其他的属性信息如下：

    

    • Propagation.REQUIRED：如果当前存在事务，则加入该事务，如果当前不存在事务，则创建一个新的事务。 也就是说如果A方法和B方法都添加了注解，在默认传播模式下，A方法内部调用B方法，会把两个方法的事务合并为一个事务

    • Propagation.SUPPORTS：如果当前存在事务，则加入该事务；如果当前不存在事务，则以非事务的方式继续运行

    • Propagation.MANDATORY：如果当前存在事务，则加入该事务；如果当前不存在事务，则抛出异常

    • Propagation.REQUIRES_NEW：重新创建一个新的事务，如果当前存在事务，暂停当前的事务。( 当类A中的 a 方法用默认Propagation.REQUIRED模式，类B中的 b方法加上采用 Propagation.REQUIRES_NEW模式，然后在 a 方法中调用 b方法操作数据库，然而 a方法抛出异常后，b方法并没有进行回滚，因为Propagation.REQUIRES_NEW会暂停 a方法的事务 )

    • Propagation.NOT_SUPPORTED：以非事务的方式运行，如果当前存在事务，暂停当前的事务

    • Propagation.NEVER：以非事务的方式运行，如果当前存在事务，则抛出异常

    • Propagation.NESTED ：和 Propagation.REQUIRED 效果一样

  • isolation属性

    事务的隔离级别，默认值为 Isolation.DEFAULT

    • Isolation.DEFAULT：使用底层数据库默认的隔离级别。

    • Isolation.READ_UNCOMMITTED：读取未提交数据(会出现脏读, 不可重复读) 基本不使用

    • Isolation.READ_COMMITTED：读取已提交数据(会出现不可重复读和幻读)

    • Isolation.REPEATABLE_READ：可重复读(会出现幻读)

    • Isolation.SERIALIZABLE：串行化

  • timeout属性：事务的超时时间，默认值为 -1。如果超过该时间限制但事务还没有完成，则自动回滚事务

  • readOnly属性：指定事务是否为只读事务，默认值为 false；为了忽略那些不需要事务的方法，比如读取数据，可以设置 readonly 为 true

  • rollbackFor属性：用于指定能够触发事务回滚的异常类型，可以指定多个异常类型

  • noRollbackFor属性：抛出指定的异常类型，不回滚事务，也可以指定多个异常类型

🍁场景一：@Transactional应用在非 public 修饰的方法上

@Transactional注解修饰的方法必须是public修饰的，同样的@Transactional修饰类时，也只有类中使用pulbic修饰的方法才能成为事务。

须知：使用@Transactional修饰的方法，必须是public修饰、非static修饰、非final修饰的，一个不满足就会导致事务失效

原因：

由于Spring的事务是通过AOP实现的，在AOP代理时，事务拦截器TransactionInterceptor在目标方法执行前后进行拦截，DynamicAdvisedInterceptor（CGlib动态代理时的事务拦截器）的 intercept 方法或 JdkDynamicAopProxy （JDK动态代理时的代理对象）的 invoke 方法都会间接调用 AbstractFallbackTransactionAttributeSource的 computeTransactionAttribute 方法，获取Transactional 注解的事务配置信息，如下图所示：

备注：在老版本的Spring中，这个需要十分注意，因为当我们在非pulic方法上加@Transactional，它在编译阶段是没有任何报错信息的，但是新版的Spring是能够在编译阶段就能够进行报错，所以只要是使用较新版本的版本，基本没可能会犯这种错误，比如我当前使用的Spring版本是5.2.15，直接就在编译阶段报错了：

🍁场景二： propagation 属性设置错误

当我们将propagation属性的值设置为一下几种取值就会导致事务失效：

1. Propagation.NOT_SUPPORTED：以非事务的方式运行，如果当前存在事务，暂停当前的事务

2. Propagation.NEVER：以非事务的方式运行，如果当前存在事务，则抛出异常

🍁场景三：rollbackFor属性设置错误

Spring默认抛出了未检查unchecked异常（继承自 RuntimeException 的异常）或者 Error才回滚事务；其他异常不会触发回滚事务。如果在事务中抛出其他类型的异常，但却期望 Spring 能够回滚事务，就需要指定 rollbackFor属性；若在目标方法中抛出的异常是 rollbackFor 指定的异常的子类，事务同样会回滚。

[

Spring底层通过getDepth方法来判断出现异常是否需要进行事务回滚

🍁场景四：方法调用导致@Transactional失效

同一个类中，A方法是非事务性方法，但是B方法是事务性方法，此时A调用B就会导致B的事务失效。

原因：

这个和场景一的原因是类似的，事务的实现是基于AOP的，而AOP的实现又是基于动态代理的，而动态代理的本质就算对方法的增强，如果想要使用增强的方法（也就是想要使用事务方法），就必须是通过代理对象去触发目标对象的方法，这个我相信只要学过设计模式都是能够理解的。

解决方案：

通过AopContext.currentProxy()这个API获取当前类的代理对象

示例：

@Service
Class ServiceImpl implements IService{
    // 普通方法
	@Override
    public Result A() {
        ......
        IService proxy = (Iservice) AopContext.currentProxy();
        return proxy.B();
    }
	// 事务方法
    @Override
    @Transactional
    public Result B() {
        ......
        return Result.ok();
    }
}

推荐阅读：每日一个设计模式之【代理模式】

🍁场景五：异常捕获导致@Transactional失效

当一个事务方法中抛出了异常，此时该异常通过try...catch进行了捕获，此时就会导致该方法的事务注解@Transactional失效

示例：

@Resource
private IBService bService;

@Service
Class AServiceImpl implements IAService{
    @Transactional
    public Result A(Student s) {
     	try {
            bService.save(s);
        } catch (Exception e) {
            e.printStackTrace();
        }
        return Result.ok();
    }
}

此时会报错org.springframework.transaction.UnexpectedRollbackException: Transaction rolled back because it has been marked as rollback-only

原因：因为bService执行save方法过程中出现了异常，所以bService告诉事务管理器，当前事务需要被rollback，但是aService中使用try...catch捕获了异常，它认为当前事务并没有发生异常，程序是处于正常状态，于是aService就告诉事务管理器，当前事务需要被commit，结果事务管理器发现收到两个矛盾的信号，它也搞不清是该rollback还是该commit，于是就抛了个UnexpectedRollbackException异常。

也就是说Spring中，事务是在方法调用时开始的，业务方法执行完毕后才执行rollback或commit操作，事务是否被回滚取决于是否抛出异常，且该异常是否满足场景三（也就是说抛出的异常是否有被rollbackFor指定，或rollbackFor指定异常的子类）。如果一定要使用try..catch时，一定要抛出异常（且抛出的异常必须满足场景三，一般直接抛一个运行时异常就可以了 throw new RuntimeException()，运行时异常是rollbackFor默认指定的异常），而不只是打印异常信息。

综上所诉：在Service层中，方法中最好不要随便写try...catch，如果写了则一定要手动抛异常

🍁场景六：数据库引擎不支持事务

Spring的事务本质还是得靠数据库引擎的支持，如果数据库引擎不支持事务，那么Spring就算使用事务也是白搭。常用的MySQL数据库默认使用支持事务的innodb引擎。一旦数据库引擎切换成不支持事务的myisam，那事务就从根本上失效了。当然相信这个问题出现的概率很小，但并不代码没有，我们还是需要有一定了解的

注意：从 MySQL 5.5.5 开始的默认存储引擎是：InnoDB，之前默认的都是：MyISAM。也就是说是从MySQL5.5.5开始，MySQL才支持事务

🍁场景七：未启用事务

想要@Transactional注解实现声明式事务，首先就需要开启事务，开启事务就三步：

1. 配置事务管理器
2. 开启事务的注解驱动
3. 使用@Transactional

PS：这个事件对于向我这种初学者来说概率还是存在的，对于老手应该不太可能会出现这种低级错误了😄

开启事务相关配置：

    <!--配置事务管理器-->
    <bean id="transactionManager" class="org.springframework.jdbc.datasource.DataSourceTransactionManager">
        <property name="dataSource" ref="dataSourceRef"></property>
    </bean>

    <!--开启事务的注解驱动，将事务管理器中的环绕通知作用到连接点，连接点使用@Transactional进行标识
    transaction-manager属性用于指定事务管理器，默认是transactionManager这个id名
    -->
    <tx:annotation-driven transaction-manager="transactionManager"/>

备注：在SpringBoot中，只需要在启动类上添加@EnableAspectJAutoProxy(exposeProxy = true)这个注解，就能使用基于注解实现的声明式事务了，等价于上面的配置

🍁场景八：Bean没有纳入Spring容器管理

Sprinｇ的事务管理核心是动态代理，不是动态代理的Bean是无法进行被Spring进行事务管理的

将Bean纳入Spring容器管理的方法：

• 方式一：配置XML

   <bean id="xxx" class="xxx.xxx.xxx"></bean>
  

• 方式二：添加注解，比如：@Controller、@Service、@Repository、@Conponent……

🍁场景九：事务方法启动新线程进行异步操作

spring 的事务是通过LocalThread来保证线程安全的，事务和当前线程绑定，此时开启新线程执行业务，这个新线程的业务就会事务失效，因为事务是基于动态代理的，要想有事务，需要被动态代理。这里提供一种解决方法，可以将新的业务单独封装成一个方法，然后改方法上添加一个@Transactional，或者将这个无法单独抽取到一个类中，将该类交给IOC容器进行管理，这样就能让新线程的业务具有事务了

🍃总结

@Transactional使用事务具有几个基本的要求：

1. 必须开启注解事务
2. 事务所在类，必须要交给IOC容器进行管理
3. 事务所在目标，必须要进行动态代理
4. 事务所在方法必须要是public

总而言之，使用@Transactional来启动事务，有很多坑，对于简单的业务还是推荐直接使用注解进行事务管理，对于复杂的业务还是推荐使用XML进行事务管理

参考文章：

• 一口气说出 6种，@Transactional注解的失效场景 - 掘金 (juejin.cn)
• 咱们从头到尾说一次 Spring 事务管理（器） - 掘金 (juejin.cn)
• spring 事务失效的 12 种场景-CSDN博客

在此致谢(^^ゞ🌹🌹🌹

---

1. 事务管理器：负责产生事务并为其分配事务标识 ↩︎

2. 恢复管理器：子事务提交时，负责将子事务的日志链接到父事务的日志上，确保事务的一致性原则 ↩︎

3. 锁管理器：事务申请锁时，负责判断锁的相容性 ↩︎

4. 死锁管理器：负责检测死锁 ↩︎

5. 缓存管理器：提供对事务标识的缓存 ↩︎