一口气怼完12种@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，如下图

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

（1）将注解标注在接口方法上

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

这种错误我们还是犯得比较少的，基本上我们都会将注解标注在接