事务（2）

如果觉得写的还可以，点个赞支持一下笔者呗！你的点赞和关注会让我更快更新哦。笔者会持续更新关于Java和大数据有关的文章。目前集中精力在更新java框架的内容。

1. 书接上回

事务（1）中我们一起学习了事务。了解了事务的特性，事务的隔离级别，悲观锁和乐观锁，还详细的分析了脏读、幻读以及不可重复读，最后稍微提了一下 Spring 中的事务传播行为。这一小节我们将会通过具体的应用来更加深入的学习事务。

说到事务的应用，通常分为编程式事务和声明式事务。编程式事务，顾名思义就是将事务管理编写到我们的业务代码中，这样一来对代码有很强的侵入性；二来会编写大量的冗余代码。所以，目前基本上都是采用声明式事务。

2. Spring 中使用声明式事务

Spring 中的声明式事务是通过 AOP 方式实现的，有关 AOP 的内容，后面我们会详细的讨论。

要在 Spring 中开启事务非常的简单，只需要在相应的类或者方法上加上 @Transactional 注解即可。例如我们新建一个 UserService 类，在 insert 方法（调用 UserMapper ）上加上 @Transactional 注解。当 insert 方法被调用时，控制台会打印如下日志：

Creating new transaction with name [com.xxx.UserService.insert]: PROPAGATION_REQUIRED,ISOLATION_DEFAULT

根据这条日志，我们可以看到在执行 insert 方法时，开启了一个事务。还可以看到传播行为是 REQUIRED，隔离级别是 DEFAULT。但是这里我们并没有去指定这两项内容，显然这是 Spring 为我们设置的默认值。传播行为、隔离级别都可以通过 @Transactional 的相应属性来进行自定义设置，接下来我们看一下 @Transactional 的源码：

package org.springframework.transaction.annotation;
......
@Target({ElementType.METHOD, ElementType.TYPE})
@Retention(RetentionPolicy.RUNTIME)
@Inherited
@Documented
public @interface Transactional {
  // 通过 bean name 设置事务管理器
  @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 {};
}

@Transactional 的源码很简单，通过上面的注释理解起来应该没什么难度。使用 @Transactional 是声明式事务的方式，与编程式事务不同，声明式事务是通过一个标识来告诉 Spring 我要在这里开启事务了。所以这种需要双方配合才能完成的事情，在事前一定要做好相应的约定。我们通过下图来一起看看 Spring 是如何进行事务管理的：

网络异常，图片无法展示

如上图所示，在执行带有 @Transactional 标识的方法时，Spring 会为其开启事务，如果方法中的业务逻辑一切正常，那么就万事大吉，Spring 会 commit 提交事务并释放资源；如果在执行业务逻辑的时候不幸发生了异常（并且是需要事务回滚的异常类型），那么 Spring 则会 rollback 将事务进行回滚并释放资源。

3. Spring 中的事务传播行为

在上一节中我们了解到事务具有四个特性 ——ACID。其中 A 代表原子性，意思是一个事务要么成功（将结果写入数据库），要么失败（不对数据库有任何影响）。这种方式在一个事务单打独斗的时候是一个非常好的做法，但是如果在一个批量任务里（假设包含 1000 个独立的任务），前面的 999 个任务都非常顺利、完美、漂亮、酷毙且成功的执行了，等到执行最后一个的时候，结果这个任务非常悲催、很是不幸的失败了。这时候 Spring 对着前面 999 个成功执行的任务大手一挥说：兄弟们，我们有一个任务失败了，现在全体恢复原状！如果这样的话，那可真是「一顿操作猛如虎，定睛一看原地杵」。

显然，Spring 并不会这么简单粗暴的处理。在 Spring 中，当一个方法调用另外一个方法时，可以让事务采取不同的策略工作，如新建事务或者挂起当前事务等，这便是事务的传播行为。上一小节我们了解到，Spring 为我们提供了七种传播行为的策略，通过枚举类 Propagation 定义，源码如下：

package org.springframework.transaction.annotation;
import org.springframework.transaction.TransactionDefinition;
public enum Propagation {
    /**
     * 需要事务，它是默认传播行为，如果当前存在事务，就沿用当前事务，
     * 去否则新建一个事务运行内部方法
     */
    REQUIRED(TransactionDefinition.PROPAGATION_REQUIRED),
    /**
     * 支持事务，如果当前存在事务，就沿用当前事务，
     * 如果不存在，则继续采用无事务的方式运行内部方法
     */
    SUPPORTS(TransactionDefinition.PROPAGATION_SUPPORTS),
    /**
     * 必须使用事务，如果当前没有事务，则会抛出异常，
     * 如果存在当前事务，则沿用当前事务
     */
    MANDATORY(TransactionDefinition.PROPAGATION_MANDATORY),
    /**
     * 无论当前事务是否存在，都会创建新事务运行方法，
     * 这样新事务就可以拥有新的锁和隔离级别等特性，与当前事务相互独立
     */
    REQUIRES_NEW(TransactionDefinition.PROPAGATION_REQUIRES_NEW),
    /**
     * 不支持事务，当前存在事务时，将挂起事务，运行方法
     */
    NOT_SUPPORTED(TransactionDefinition.PROPAGATION_NOT_SUPPORTED),
    /**
     * 不支持事务，如果当前方法存在事务，则抛出异常，否则继续使用无事务机制运行
     */
    NEVER(TransactionDefinition.PROPAGATION_NEVER),
    /** 
     * 在当前方法调用内部方法时，如果内部方法发生异常，
     * 只回滚内部方法执行过的 SQL ，而不回滚当前方法的事务
     */
    NESTED(TransactionDefinition.PROPAGATION_NESTED);
    ......
}

接下来我们通过对其中三种最常用的（REQUIRED、REQUIRES_NEW、NESTED）策略进行对比来更深入的理解。以下测试均在外部方法开启事务的情况下进行，因为在外部没有事务的情况下，三者都会新建事务，效果一样。

3.1 REQUIRED

当内部方法的事务传播行为设置为 REQUIRED 时，内部方法会加入外部方法的事务，可以看到日志中有 **Participating in existing transaction ** 这样一行内容：

# 开启事务
Creating new transaction with name [com.imooc.springboot.transaction.service.TransactionService.batchInsert]: PROPAGATION_REQUIRED,ISOLATION_DEFAULT,-java.lang.Exception
.........
# 加入当前事务
Participating in existing transaction
.........
# 提交事务
Initiating transaction commit

3.2 REQUIRES_NEW

当内部方法的传播行为设置为 REQUIRES_NEW 时，内部方法会先将外部方法的事务挂起，然后开启一个新的事务可以看到日志中有 Suspending current transaction, creating new transaction… 这样一行内容：

# 开启外部事务
Creating new transaction with name [com.imooc.springboot.transaction.service.TransactionService.batchInsert]: PROPAGATION_REQUIRES_NEW,ISOLATION_DEFAULT,-java.lang.Exception
..........
# 挂起当前事务，并开启新事务
Suspending current transaction, creating new transaction with name [com.imooc.springboot.transaction.service.UserService.insert]
..........
# 提交内部方法事务
Initiating transaction commit
# 唤醒被挂起的外部事务
Resuming suspended transaction after completion of inner transaction
# 提交外部事务
Initiating transaction commit

3.3 NESTED

当内部方法的传播行为设置为 NESTED 时，内部方法会开启一个新的嵌套事务可以看到日志中有 Creating nested transaction… 这样一行内容：

# 开启主事务
Creating new transaction with name [com.imooc.springboot.transaction.service.TransactionService.batchInsert]:  PROPAGATION_NESTED,ISOLATION_DEFAULT,-java.lang.Exception
..........
# 开启嵌套事务
Creating nested transaction with name [com.imooc.springboot.transaction.service.UserService.insert]
..........
# 释放保存点
Releasing transaction savepoint
# 提交事务
Initiating transaction commit

另外，每个 NESTED 事务执行前会将当前操作保存下来，叫做 savepoint （保存点），如果当前 NESTED 事务执行失败，则回滚到之前的保存点，以便之前的执行结果不受当前 NESTED 事务的影响。NESTED 事务在外部事务提交以后自己才会提交。

3.4 区别

REQUIRES_NEW 最为简单，不管当前有无事务，它都会开启一个全新事务，既不影响外部事务，也不会影响其他内部事务，真正的井水不犯河水，坚定而独立。

REQUIRED 在没有外部事务的情况下，会开启一个事务，不影响其他内部事务；而当存在外部事务的情况下，则会与外部事务还有其他内部事务同命运共生死。有条件会直接上，没条件是会自己创造条件，然后再上。

NESTED 在没有外部事务的情况下与 REQUIRED 效果相同；而当存在外部事务的情况下，则与外部事务生死与共，但与其他内部事务互不相干。要么孑然一身，要么誓死追随主公（外部事务）。

4. 拓展

在大部分数据库中，一段 SQL 语句中可以设置一个标志位，如果标志位后面的代码执行过程中发生异常，则只需回滚到这个标志位的数据状态，而不会让这个标志位之前的代码也回滚。这个标志位，在数据库的概念中被称为保存点（savepoint）。Spring 传播行为中 NESTED 策略就是利用数据库保存点的技术实现的。但需要注意的是，有一些数据库是不支持保存点的，这个时候 NESTED 策略就会像 REQUIRES_NEW 一样创建一个全新的事务（而非嵌套事务）。但此时二者仍有一些不同，NESTED 传播行为会沿用外部事务的隔离级别和锁等特性，而 REQUIRES_NEW 则可以拥有自己独立的隔离级别和锁等特性，这一点小区别在实际应用中要注意。

事务详解（2）