小伙伴大家好，我是 jack xu，今天跟大家讲一讲 @Transactional，这个注解相信大家应该都用过，它能保证方法内多个数据库操作要么同时成功、要么同时失败。使用 @Transactional 注解时需要注意许多的细节，虽然它看起来简单，但不知道底层原理的话，用起来往往达不到我们想要的效果。
事务分为编程式事务和声明式事务两种。编程式事务指在代码中手动的管理事务的提交、回滚等操作，代码侵入性比较强。声明式事务是基于 AOP 面向切面的，它将具体业务与事务处理部分解耦，代码侵入性很低，声明式事务也有两种实现方式，一种是基于 TX 和 AOP 的 xml 配置文件方式，二种就是基于 @Transactional 注解了，实际开发中 @Transactional 用的比较多。
@Transactional 可以作用在类上，当作用在类上的时候，表示所有该类的 public 方法都配置相同的事务属性信息。@Transactional 也可以作用在方法上，当方法上也配置了 @Transactional，方法的事务会覆盖类的事务配置信息。
今天我们通过看 @Transactional 的源码来和大家重新认识一下 @Transactional 的用法。
源码
我们从 @Transactional 点进去，看到里面有很多的属性，我们来依次分析一下。
@Target({ElementType.TYPE, ElementType.METHOD})
@Retention(RetentionPolicy.RUNTIME)
@Inherited
@Documented
public @interface Transactional {
@AliasFor("transactionManager")
String value() default "";
@AliasFor("value")
String transactionManager() default "";
Propagation propagation() default Propagation.REQUIRED;
Isolation isolation() default Isolation.DEFAULT;
int timeout() default TransactionDefinition.TIMEOUT_DEFAULT;
boolean readOnly() default false;
Class<? extends Throwable>[] rollbackFor() default {};
String[] rollbackForClassName() default {};
Class<? extends Throwable>[] noRollbackFor() default {};
String[] noRollbackForClassName() default {};
}
transactionManager 和 value 是一组： 大多数项目只需要一个事务管理器，但是在有些项目中为了提高效率、或者有多个完全不同又不相干的数据源，所以会有多个事务管理器，这里填的就是你想用的事务管理器的 Bean 的 id。
isolation属性： 是事务的隔离级别，默认值为 Isolation.DEFAULT。这里有四个隔离级别，在Innodb里面默认用的是 RR 级别，具体这四个级别是什么意思，等后面写 LBCC 和 MVCC 的时候再和大家介绍。
- Isolation.DEFAULT：使用底层数据库默认的隔离级别。
- Isolation.READ_UNCOMMITTED
- Isolation.READ_COMMITTED
- Isolation.REPEATABLE_READ
- Isolation.SERIALIZABLE
timeout属性： 事务的超时时间，默认值为-1。如果超过该时间限制但事务还没有完成，则自动回滚事务。
readOnly属性 ： 指定事务是否为只读事务，默认值为false；为了忽略那些不需要事务的方法，比如读取数据，可以设置 read-only 为 true。
rollbackFor属性 ： 用于指定能够触发事务回滚的异常类型，可以指定多个异常类型。
现在我们来看个例子，来加深下这个属性的用法。这里我写了一个转账的方法，里面抛了一个InterruptedException 异常，此时数据库的事务会回滚吗？
执行一下，报错了
我们来看下数据库，金额产生变化了，之前是 1000 和 0 的，现在变成了 900 和 100，这和我们预期的不符啊，我们想的是发生异常了，事务将进行回滚，怎么还能执行成功呢？
不要慌，现在我们来换一个异常，此时换成了抛出一个运行时异常。
再执行一下
我们看下数据库还是 1000 和 0，完好无损，说明回滚成功了。
那为什么两个异常，一个异常回滚成功了，一个异常回滚失败呢，现在我们来看下源码。看到这里小伙伴明白了吗，原来回滚是只判断异常类型是 RuntimeException 和 Error 的才会进行回滚，别的异常类型是不会回滚的。
看到这里小伙伴可能有点懵，什么是 RuntimeException 类型和 Error 类型呢，这里我用 idel 的工具画了一个 UML 类图，小伙们可以看下，RuntimeException 和 Error 我也用红框圈出来了。所以小伙伴如果想要捕获所有的异常，这时候就可以用 @Transactional(rollbackFor = Exception.class)，这是一个偷懒的写法，当然这里也可以指定多个，可以指定自己的业务异常等等。
noRollbackFor属性： 这个就是和上面相反的了，抛出指定的异常类型，不回滚事务，也可以指定多个异常类型。
最后说下propagation属性，这个也是本篇文章的核心重点，它一共有七种传播行为，我们来分别看下。
| 传播行为 | 说明 |
|---|---|
| Propagation.REQUIRED | 如果当前存在事务，则加入该事务，如果当前不存在事务，则创建一个新的事务。 |
| Propagation.SUPPORTS | 如果当前存在事务，则加入该事务；如果当前不存在事务，则以非事务的方式继续运行。 |
| Propagation.MANDATORY | 如果当前存在事务，则加入该事务；如果当前不存在事务，则抛出异常。 |
| Propagation.REQUIRES_NEW | 重新创建一个新的事务，如果当前存在事务，暂停当前的事务。 |
| Propagation.NOT_SUPPORTED | 以非事务的方式运行，如果当前存在事务，暂停当前的事务。 |
| Propagation.NEVER | 以非事务的方式运行，如果当前存在事务，则抛出异常。 |
| Propagation.NESTED | 和 Propagation.REQUIRED 效果一样。 |
当我们不指定的时候默认使用的是 Propagation.REQUIRED，另外两个常用的是 Propagation.REQUIRES_NEW 和 Propagation.NESTED，而另外四种我们基本是不会去使用的，所以小伙伴也没必要去了解，那么这几个传播行为到底是什么意思，我们光看概念可能一头雾水，不知所云，没关系，接下来我将用实战演练的方式来带大家领略下到底怎么用法。
实战演练
实验一
首先我们写三个 service 方法
UserMoneyService 里面有一个总的方法，上面加了一个 @Transactional，里面干两件事，一个是记录转账日志，一个是进行转账操作。 
我们把 logService 点进去，里面有个记录转账日志方法，方法上也加上一个 @Transactional，并且在方法内部抛出一个异常。 
我们把 moneyService 点进去，里面有个转账操作方法，方法上也加了一个 @Transactional。 
现在大家逻辑关系都搞清楚了吧，一个大的 @Transactional 里面有两个小的 @Transactional。此时我运行一下，大家猜下结果会是怎样，有哪些是执行成功，哪些是执行失败，还是都成功还是都失败？
思考一分钟，我们继续往下走。执行一下，报错了
我们看下数据库，用户表金额没有变 
转账日志表也没有插入数据 
看来是一样都没有执行成功，这个是什么原因呢？我们来分析下，我这里画了个伪代码，在 logService.addChangeLog 中报错了，然后被捕捉到，然后进行事务的回滚，回滚完之后干了一个重要的事情，那就是 throw ex，把异常又向外抛出了，此时被外层的 try catch 给捕捉到了，所以代码自然也不会向下执行，moneyService.changeUserMoney 没有被执行到，所以数据库里的值都没有产生变化。 
小伙伴看到我画的伪代码，可能认为我是在一派胡言，没关系，我给大家看下源码，它确实是这么干的。
实验二
现在我们在记录转账日志的方法上做一个小改变，把传播行为改成 REQUIRES_NEW，此时是开启了一个新的事务，此时小伙伴再猜想下，表里的数据将会做如何的变化？
思考一分钟，执行一下，继续报错
看下结果，数据库里两张表的数据都没有产生变化 
不是小伙伴有没有猜对，其实这个原理和上面是一样的，不管是 REQUIRES 还是 REQUIRES_NEW ，在 logService.addChangeLog 捕获到异常后都会向外抛出异常，外层捕获到异常后代码将不会向下执行。
实验三
此时 logService.addChangeLog 上的传播属性还是 REQUIRES_NEW
moneyService.changeUserMoney 操作使用的是默认传播行为，此时把方法异常移动到了这里面了，现在大家再猜下数据库的数据又将做如何变化？ 
思考一分钟，执行一下，依然报错
我们在来看数据库，此时日志表已经有记录了，用户表里的金额还是没有变化，这个大家可以理解吧，因为记录转账日志表在前面已经先执行了，而且日志表开启了一个新的事务，所以在执行完直接提交数据库成功了，而 moneyService.changeUserMoney 报错了，回滚然后抛出异常，自然不会影响上面的代码，所以结果就是日志表记录了，用户表数据没有变化。
实验四
现在我把 logService.addChangeLog，moneyService.changeUserMoney 传播属性都改为 REQUIRES_NEW，并且在转账操作中抛异常，此时数据库又该做如何变化？
执行一下，直接看数据库，日志表记录了，转账记录没有变化，小伙伴答对了吗。此时相当于开了三个事务连接，各干各的，原理同上面一样，日志表的先行提交，转账记录报错不影响它。
实验五
现在 logService.addChangeLog，moneyService.changeUserMoney 的传播属性还是REQUIRES_NEW，只是这次我把异常移到日志操作里来了，此时数据又该做如何变化？
执行一下，在看数据库，日志表和用户表都没有变化，你们答对了吗，还是实验二的原理，不管是 REQUIRES 还是 REQUIRES_NEW，logService.addChangeLog 在捕获到异常后都会向外抛出异常，外层异常捕获到后代码将不会往下走，异常后面的不管你十个八个都不会执行。
那么碰到这种情况怎么办，很简单，加一个 try catch，我们在很多源码中也看到空的 catch ,里面什么事情都没有做，目的就是自己的异常自己吃掉，不向外抛，不影响上层建筑，也就是不影响别的事务。
到这里小伙伴不知道有没有被我的连环炮击给绕晕，没关系，只要理解我讲的原理以后，不管你怎么变还是那么多套路，最后我们来看一下嵌套事务。
实验六
嵌套事务其实是没开启事务，效果跟 REQUIRED 一样，只是多了一个 addPoint 记录切入点。此时我把 logService.addChangeLog，moneyService.changeUserMoney 传播行为都改成了 NESTED，并且在转账操作中抛出一个异常，此时小伙伴在猜下，这是最后一道题了，争取答对哦！
思考半分钟，执行一下
查看数据库发现都没有产生变化，日志也没记，金额也没变。
嵌套事务也叫寄生事务，里面两个事务和最外面的事务其实用的是同一个数据库连接。所以当moneyService.changeUserMoney 报错的时候，向外抛出异常，外层捕捉到后由于使用的是同一个连接，所以将这个连接上干的所有事情都进行回滚，从而数据库里一样也没有执行成功。
通过这六个实验，小伙们应该对传播行为有了更深的了解了吧，如果你还记不住，或者搞不清楚，没关系，像我一样做实验，光说不练假把式，光看你说能看会吗？
失效场景
到这里我们差不多也要接近尾声了，最后我们来说下 @Transactional 的失效场景。
1、@Transactional 应用在非 public 修饰的方法上，@Transactional 将会失效。protected、private 修饰的方法上使用 @Transactional 注解，虽然事务无效，但不会有任何报错，这是我们很容犯错的一点。
2、@Transactional 注解属性 propagation 设置错误。PROPAGATION_SUPPORTS、PROPAGATION_NOT_SUPPORTED、PROPAGATION_NEVER上面这三种我都没有讲到，因为用了它们事务是不会发生回滚，加了等于没加。
3、@Transactional 注解属性 rollbackFor 设置错误，这个上面演示给大家看了，默认的只会对 RuntimeException 类型和 Error 类型的才进行回滚。如果在事务中抛出其他类型的异常，却希望 Spring 能够回滚事务，就需要指定 rollbackFor 属性。
4、同一个类中方法调用，导致 @Transactional 失效。这个我在上面做实验的时候已经演示过了，总方法调子方法的时候，要放在不同的 service 里面，如果放在一个类里面，事务调用是不会生效的。
5、异常被吃了，这个在实验五里面也说了，吃掉以后虽然不影响其他事务，但是其他数据的 commit 会造成数据不一致，所以有些时候 try catch 反倒会画蛇添足。
6、数据库引擎不支持事务，这一点很简单，myisam 引擎是不支持事务的，innodb 引擎支持事务。
7、数据源没有配置事务管理器，这个也很简单，要使用事务肯定要配事务管理器。Hibernate 用的是HibernateTransactionManager，JDBC 和 Mybatis 用的是 DataSourceTransactionManager。
8、最后就是一个方法内多数据库（多数据源）的情况下会失效，这个也是我同事做实验得出来的。
总结：@Transactional 注解的看似简单易用，但如果对它的用法一知半解，还是会踩到很多坑的。本文不一定总结得全，但是会了这么多足以应付工作中碰到的问题，最后原创不易，如果你觉得写的不错，请点一个赞！
