Spring @Transactional注解失效情况

数据库事务是后端开发中不可缺少的一块知识点。Spring 为了更好的支撑我们进行数据库操作，在框架中支持了两种事务管理的方式：

- 编程式事务
- 声明式事务

日常我们进行业务开发时，基本上使用的都是声明式事务，即为使用 @Transactional 注解的方式。

常规使用时，Spring 能帮我们很好的实现数据库的 ACID **（这里需要注意哦，Spring 只是进行了编程上的事务，最终数据上的事务还是有数据库实现的）** 。

但是，只要是人写的代码，就一定会有 Bug。

如果我们不了解 @Transactional 的失效场景或者说踩坑点，那么在业务开发的过程中总是会出现一些匪夷所思的 Bug。

本文将罗列 @Transactional 的失效场景，并分析其失效原因。

## 一、失效场景集一：代理不生效

Spring 中对注解解析的尿性都是基于代理的，如果目标方法无法被 Spring 代理到，那么它将无法被 Spring 进行事务管理。

**Spring 生成代理的方式有两种：**

1. 基于接口的 JDK 动态代理，要求目标代理类需要实现一个接口才能被代理
2. 基于实现目标类子类的 CGLIB 代理

Spring 在 2.0 之前，目标类如果实现了接口，则使用 JDK 动态代理方式，否则通过 CGLIB 子类的方式生成代理。

而在 2.0 版本之后，如果不在配置文件中显示的指定 spring.aop.proxy-tartget-class 的值，默认情况下生成代理的方式为 CGLIB，如下图

![](/media/202311/2023-11-22_1620300.22461715040957286.png)

顺着代理的思路，我们来看看哪些情况会因为代理不生效导致事务管控失败。

### 将注解标注在接口方法上

@Transactional 是支持标注在方法与类上的。一旦标注在接口上，对应接口实现类的代理方式如果是 CGLIB，将通过生成子类的方式生成目标类的代理，将无法解析到 @Transactional，从而事务失效。

这种错误我们还是犯得比较少的，基本上我们都会将注解标注在接口的实现类方法上，官方也不推荐这种。

### 被 final、static 关键字修饰的类或方法

CGLIB 是通过生成目标类子类的方式生成代理类的，被 final、static 修饰后，无法继承父类与父类的方法。

### 类方法内部调用

事务的管理是通过代理执行的方式生效的，如果是方法内部调用，将不会走代理逻辑，也就调用不到了。

例如：

![](/media/202311/2023-11-22_1620300.997056739997266.png)

在**createUser**中调用了内部方法**createUser1**，并且**createUser1**方法上设置了事务传播策略为：**REQUIRES\_NEW**，但是因为是内部直接调用，createUser1 不能不代理处理，无法进行事务管理。在 createUser1 方法抛出异常后就插入数据失败了。

**但是这种操作在我们业务开发的过程中貌似还挺常见的，怎么样才能保证其成功呢？**

方式 1：新建一个 Service，将方法迁移过去，有点麻瓜。

方式 2：在当前类注入自己，调用 createUser1 时通过注入的 userService 调用

![](/media/202311/2023-11-22_1620300.34249139609277346.png)

方式 3：通过 AopContext.currentProxy()获取代理对象

![](/media/202311/2023-11-22_1620300.07338046523804853.png)

道理类似于方式 2，就是为了通过代理来访问内部方法

### 当前类没有被 Spring 管理

这个没什么好说的，都没有被 Spring 管理成为 IOC 容器中的一个 bean，更别说被事务切面代理到了。

这种 Bug 看上去比较蠢，但没准真的有人犯错。

## 二、失效场景集二：框架或底层不支持的功能

这类失效场景主要聚焦在框架本身在解析 @Transactional 时的内部支持。如果使用的场景本身就是框架不支持的，那事务也是无法生效的。

### 非 public 修饰的方法

我们在标有 @Transactional 的任意方法上打个断点，在 idea 内能看到事务切面点如下图所示

![](/media/202311/2023-11-22_1620300.6120668895401297.png)

点击去这个方法，在开头有这么一个调用

![](/media/202311/2023-11-22_1620300.6536131436100886.png)

继续进去

![](/media/202311/2023-11-22_1620300.9072700957592815.png)

就能看到这么一句话了

![](/media/202311/2023-11-22_1620300.7300255385776325.png)

不支持非 public 修饰的方法进行事务管理。

### 多线程调用

跟上面一样的的操作，我们能够逐层进入到 TransactionAspectSupport.prepareTransactionInfo 方法。

注意看以下这段话

![](/media/202311/2023-11-22_1620300.8385871676540719.png)

从这里我们得知，事务信息是跟线程绑定的。

因此在多线程环境下，事务的信息都是独立的，将会导致 Spring 在接管事务上出现差异。

**这个场景我们要尤其注意！**

给大家举个例子

主线程 A 调用线程 B 保存 Id 为 1 的数据，然后主线程 A 等待线程 B 执行完成再通过线程 A 查询 id 为 1 的数据。

这时你会发现在主线程 A 中无法查询到 id 为 1 的数据。因为这两个线程在不同的 Spring 事务中，本质上会导致它们在 Mysql 中存在不同的事务中。

Mysql 中通过 MVCC 保证了线程在快照读时只读取小于当前事务号的数据，在线程 B 显然事务号是大于线程 A 的，因此查询不到数据。

### 数据库本身不支持事务

比如 Mysql 的 Myisam 存储引擎是不支持事务的，只有 innodb 存储引擎才支持。

这个问题出现的概率极其小，因为 Mysql5 之后默认情况下是使用 innodb 存储引擎了。

但如果配置错误或者是历史项目，发现事务怎么配都不生效的时候，记得看看存储引擎本身是否支持事务。

### 未开启事务

这个也是一个比较麻瓜的问题，在 Springboot 项目中已经不存在了，已经有**DataSourceTransactionManagerAutoConfiguration**默认开启了事务管理。

但是在 MVC 项目中还需要在 applicationContext.xml 文件中，手动配置事务相关参数。如果忘了配置，事务肯定是不会生效的。

## 三、失效场景集三：错误使用 @Transactional

注意啦注意啦，下面这几种都是高频会出现的 Bug！

### 错误的传播机制

Spring 支持了 7 种传播机制，分别为：

![](/media/202311/2023-11-22_1620300.6942851569939186.png)

上面不支持事务的传播机制为：PROPAGATION\_SUPPORTS，PROPAGATION\_NOT\_SUPPORTED，PROPAGATION\_NEVER。

如果配置了这三种传播方式的话，在发生异常的时候，事务是不会回滚的。

### rollbackFor 属性设置错误

![](/media/202311/2023-11-22_1620300.6061543903380581.png)

默认情况下事务仅回滚运行时异常和 Error，不回滚受检异常（例如 IOException）。

因此如果方法中抛出了 IO 异常，默认情况下事务也会回滚失败。

我们可以通过指定 @Transactional(rollbackFor = Exception.class)的方式进行全异常捕获。

### 异常被内部 catch

UserService

![](/media/202311/2023-11-22_1620300.556031242253512.png)

UserService1

![](/media/202311/2023-11-22_1620300.7587355257555695.png)

如上代码 UserService 调用了 UserService1 中的方法，并且捕获了 UserService1 中抛出的异常。

你将能看到控制台出现这样一个报错：

```text
org.springframework.transaction.UnexpectedRollbackException: Transaction rolled back because it has been marked as rollback-only
复制代码
```

默认情况下标注了 @Transactional 注解的方法的事务传播机制是**REQUIRED**，它的特性是支持当前事务，也就说加入当前事务。我们在 UserService 中开始事务，然后再 UserService1 中抛出异常回滚 UserService 中的事务，将其标记为只读。

但是在 UserSevice 中我们捕获了异常，此时 UserService 上的事务认为正常提交事务。最后在提交时发现事务只读，已经被回滚，则抛出了上述异常。

**因此这里如果需要对特定的异常进行捕获处理，记得再次将异常抛出，让最外层的事务感知到。**

### 嵌套事务

上面是我想同时回滚 UserService 与 UserService1。但是也会有这种场景只想回滚 UserService1 中报错的数据库操作，不影响主逻辑 UserService 中的数据落库。

有两种方式可以实现上述逻辑：

1.直接在 UserService1 内的整个方法用 try/catch 包住

2.在 UserService1 使用 Propagation.REQUIRES\_NEW 传播机制

![](/media/202311/2023-11-22_1620300.3190816749488413.png)

## 四、总结

本文为大家分析 @Transactional 注解使用过程中失效的 12 种场景

![](/media/202311/2023-11-22_1620300.6400903803646504.png)

最后，@Transactional 注解虽香，但是复杂业务逻辑下，为了更好的管理事务与把控业务处理时事务的细粒度，我还是推荐大家使用编程式事务。