一、事务 隔离级别

事务特性回顾

事务有4 ⼤特性（ACID），原⼦性、持久性、⼀致性、隔离性，具体概念如下：

• 原⼦性：⼀个事务（transaction）中的所有操作，要么全部完成，要么全部不完成，不会结束在中间某个环节。事务在执⾏过程中发⽣错误，会被回滚（Rollback）到事务开始前的状态，就像这个事务从来没有执⾏过⼀样。

• ⼀致性：在事务开始之前和事务结束以后，数据库的完整性没有被破坏。这表示写⼊的资料必须完 全符合所有的预设规则，这包含资料的精确度、串联性以及后续数据库可以⾃发性地完成预定的⼯

作

• 持久性：事务处理结束后，对数据的修改就是永久的，即便系统故障也不会丢失。

• 隔离性：数据库允许多个并发事务同时对其数据进⾏读写和修改的能⼒，隔离性可以防⽌多个事务并发执⾏时由于交叉执⾏⽽导致数据的不⼀致。

事务隔离分为不同级别，包括读未提交（Read uncommitted）、读提交（read committed）、可重复读（repeatable read） 和 串⾏化（Serializable）

---

上⾯ 4 个属性，可以简称为ACID

1. 原⼦性（Atomicity，或称不可分割性）
2. ⼀致性（Consistency）
3. 隔离性（Isolation，⼜称独⽴性）
4. 持久性（Durability）

这 4 种特性中，只有隔离性（隔离级别）是可以设置的。

---

为什么要设置事务的隔离级别？

设置事务的隔离级别是⽤来保障多个并发事务执⾏更可控，更符合操作者预期的。

什么是可控呢？

⽐如近⼏年⽐较严重的新冠病毒，我们会把直接接触到确证病例的⼈员隔离到酒店，⽽把间接接触者（和直接接触着但未确诊的⼈)隔离在⾃⼰的家中，也就是针对不同的⼈群，采取不同的隔离级别，这 种隔离⽅式就和事务的隔离级别类似，都是采取某种⾏动让某个事件变的 更可控 。⽽事务的隔离级别就是为了防⽌，其他的事务影响当前事务执⾏的⼀种策略。

---

Spring 中设置事务隔离级别

Spring 中事务隔离级别可以通过 @Transactional 中的 isolation 属性进⾏设置

具体操作如下图所示：

---

① MySQL 事务隔离级别有 4 种

1. READ UNCOMMITTED：读未提交，也叫未提交读，该隔离级别的事务可以看到其他事务中未提交的数据。该隔离级别因为可以读取到其他事务中未提交的数据，⽽未提交的数据可能会发⽣回滚， 因此我们把该级别读取到的数据称之为脏数据，把这个问题称之为脏读。

2. READ COMMITTED：读已提交，也叫提交读，该隔离级别的事务能读取到已经提交事务的数据， 因此它不会有脏读问题。但由于在事务的执⾏中可以读取到其他事务提交的结果，所以在不同时间 的相同 SQL 查询中，可能会得到不同的结果，这种现象叫做不可重复读。

3. REPEATABLE READ：可重复读，是 MySQL 的默认事务隔离级别，它能确保同⼀事务多次查询的结果⼀致。但也会有新的问题，⽐如此级别的事务正在执⾏时，另⼀个事务成功的插⼊了某条数据，但因为它每次查询的结果都是⼀样的，所以会导致查询不到这条数据，⾃⼰重复插⼊时⼜失败（因为唯⼀约束的原因）。明明在事务中查询不到这条信息，但⾃⼰就是插⼊不进去，这就叫幻读（Phantom Read）。

4. SERIALIZABLE：串行化（序列化），事务最⾼隔离级别，它会强制事务排序，使之不会发⽣冲突，从⽽解决 了脏读、不可重复读和幻读问题，但因为执⾏效率低，所以真正使⽤的场景并不多。

• 脏读：⼀个事务读取到了另⼀个事务修改的数据之后，后⼀个事务⼜进⾏了回滚操作，从⽽导致第⼀个事务读取的数据是错误的。

• 不可重复读：⼀个事务两次查询得到的结果不同，因为在两次查询中间，有另⼀个事务把数据修

改了。

• 幻读：⼀个事务两次查询中得到的结果集不同，因为在两次查询中另⼀个事务有新增了⼀部分数据。

---

在数据库中通过以下 SQL 查询全局事务隔离级别和当前连接的事务隔离级别：

select @@global.tx_isolation,@@tx_isolation;

以上 SQL 的执⾏结果如下：

---

②Spring 事务隔离级别有 5 种

Spring 中事务隔离级别包含以下 5 种：

1. Isolation.DEFAULT：以连接的数据库的事务隔离级别为主。

2. Isolation.READ_UNCOMMITTED：读未提交，可以读取到未提交的事务，存在脏读。

3. Isolation.READ_COMMITTED：读已提交，只能读取到已经提交的事务，解决了脏读，存在不可重 复读。

4. Isolation.REPEATABLE_READ：可重复读，解决了不可重复读，但存在幻读（MySQL默认级别）。

5. Isolation.SERIALIZABLE：串⾏化，可以解决所有并发问题，但性能太低。

从上述介绍可以看出，相⽐于 MySQL 的事务隔离级别，Spring 的事务隔离级别只是多了⼀个Isolation.DEFAULT（以数据库的全局事务隔离级别为主）

---

Spring 中事务隔离级别只需要设置 @Transactional ⾥的 isolation 属性即可，具体实现代码如下：

@RequestMapping("/save")
@Transactional(isolation = Isolation.SERIALIZABLE) // 设置事务的隔离级别
public Object save(User user) {
    // 业务实现
}

---

二、Spring 事务传播机制

事务传播机制是什么？

Spring 事务传播机制定义了多个包含了事务的⽅法，相互调⽤时，事务是如何在这些⽅法间进⾏传递的。

---

为什么需要事务传播机制？

事务隔离级别是保证多个并发事务执⾏的可控性的（稳定性的），⽽事务传播机制是保证⼀个事务在多个调⽤⽅法间的可控性的（稳定性的）

例⼦：

像新冠病毒⼀样，它有不同的隔离⽅式（酒店隔离还是居家隔离），是为了保证疫情可控，然⽽在每个⼈的隔离过程中，会有很多个执⾏的环节，⽐如酒店隔离，需要负责⼈员运送、物品运送、 消杀原⽣活区域、定时核算检查和定时送餐等很多环节，⽽事务传播机制就是保证⼀个事务在传递过 程中是可靠性的，回到本身案例中就是保证每个⼈在隔离的过程中可控的

---

事务隔离级别解决的是多个事务同时调⽤⼀个数据库的问题

如下图所示：

事务传播机制解决的是⼀个事务在多个节点（⽅法）中传递的问题

如下图所示：

---

事务传播机制有哪些？

Spring 事务传播机制包含以下 7 种：

1. Propagation.REQUIRED：默认的事务传播级别，它表示如果当前存在事务，则加⼊该事务；如果当前没有事务，则创建⼀个新的事务。

2. Propagation.SUPPORTS：如果当前存在事务，则加⼊该事务；如果当前没有事务，则以⾮事务的⽅式继续运⾏。

3. Propagation.MANDATORY：（mandatory：强制性）如果当前存在事务，则加⼊该事务；如果当前没有事务，则抛出异常。

4. Propagation.REQUIRES_NEW：表示创建⼀个新的事务，如果当前存在事务，则把当前事务挂起。也就是说不管外部⽅法是否开启事务，Propagation.REQUIRES_NEW 修饰的内部⽅法会新开启⾃⼰的事务，且开启的事务相互独⽴，互不⼲扰。

5. Propagation.NOT_SUPPORTED：以⾮事务⽅式运⾏，如果当前存在事务，则把当前事务挂起。

6. Propagation.NEVER：以⾮事务⽅式运⾏，如果当前存在事务，则抛出异常。

7. Propagation.NESTED：如果当前存在事务，则创建⼀个事务作为当前事务的嵌套事务来运⾏；如 果当前没有事务，则该取值等价于 PROPAGATION_REQUIRED。

---

以上 7 种传播⾏为，可以根据是否⽀持当前事务分为以下 3 类：

以情侣关系为例来理解以上分类：

---

Spring 事务传播机制使用 及 各种场景演示

① 支持当前事务（REQUIRED）

以下代码实现中，先开启事务先成功插⼊⼀条⽤户数据，然后再执⾏⽇志报错，⽽在⽇志报错是发⽣了 异常。

观察 propagation = Propagation.REQUIRED 的执⾏结果。

@RestController
public class UserController {
    @Resource
    private UserService userService;
    @Resource
    private LogService logService;
    @RequestMapping("/save")
    @Transactional(propagation = Propagation.REQUIRED)
    public Object save(User user) {
        // 插⼊⽤户操作
        userService.save(user);
        // 插⼊⽇志
        logService.saveLog("⽤户插⼊：" + user.getName());
        return true;
   }
}

UserService 实现代码如下：插⼊⼀条⽤户数据

@Service
public class UserService {
    @Resource
    private UserMapper userMapper;
    @Transactional(propagation = Propagation.REQUIRED)
    public int save(User user) {
        System.out.println("执⾏ save ⽅法.");
        return userMapper.save(user);
   }
}

LogService 实现代码如下： 出现异常

@Service
public class LogService {
    @Resource
    private LogMapper logMapper;
    @Transactional(propagation = Propagation.REQUIRED)
    public int saveLog(String content) {
        // 出现异常
        int i = 10 / 0;
        return logMapper.saveLog(content);
   }
}

执⾏结果：

程序报错，数据库没有插⼊任何数据。

执⾏流程描述：

1. UserService 中的保存⽅法正常执⾏完成。
2. LogService 保存⽇志程序报错，因为使⽤的是 Controller 中的事务，所以整个事务回滚。
3. 数据库中没有插⼊任何数据，也就是步骤 1 中的⽤户插⼊⽅法也回滚了。

---

② 不⽀持当前事务（REQUIRES_NEW）

UserController 类中的代码不变，将添加⽤户和添加⽇志的⽅法修改为 REQUIRES_NEW 不⽀持当前事务，重新创建事务，观察执⾏结果：

UserController 类中的代码不变：

@RequestMapping("/save")
@Transactional
public Object save(User user) {
    // 插⼊⽤户操作
    userService.save(user);
    // 插⼊⽇志
    logService.saveLog("⽤户插⼊：" + user.getName());
    return true;
}

UserService 实现代码：⽅法修改为 REQUIRES_NEW

@Service
public class UserService {
    @Resource
    private UserMapper userMapper;
    @Transactional(propagation = Propagation.REQUIRES_NEW)
    public int save(User user) {
        System.out.println("执⾏ save ⽅法.");
        return userMapper.save(user);
   }
}

LogService 实现代码：⽅法修改为 REQUIRES_NEW

@Service
public class LogService {
    @Resource
    private LogMapper logMapper;
    @Transactional(propagation = Propagation.REQUIRES_NEW)
    public int saveLog(String content) {
        // 出现异常
        int i = 10 / 0;
        return logMapper.saveLog(content);
   }
}

程序执⾏结果：

User 表中成功插⼊了数据

Log 表执⾏失败，但没影响 UserController 中的事务

---

③ 不⽀持当前事务 (NEVER) 抛异常

UserController 实现代码：

@RequestMapping("/save")
@Transactional
public Object save(User user) {
    // 插⼊⽤户操作
    userService.save(user);
    return true;
}

UserService 实现代码：

@Transactional(propagation = Propagation.NEVER)
public int save(User user) {
    System.out.println("执⾏ save ⽅法.");
    return userMapper.save(user);
}

程序执⾏结果：

程序执⾏报错，⽤户表未添加任何数据。

---

④ NESTED 嵌套事务

UserController 实现代码如下：

@RequestMapping("/save")
@Transactional
public Object save(User user) {
    // 插⼊⽤户操作
    userService.save(user);
    return true;
}

UserService 实现代码如下：

@Transactional(propagation = Propagation.NESTED)
public int save(User user) {
    int result = userMapper.save(user);
    System.out.println("执⾏ save ⽅法.");
    // 插⼊⽇志
    logService.saveLog("⽤户插⼊：" + user.getName());
    return result;
}

LogService 实现代码如下：

@Transactional(propagation = Propagation.NESTED)
public int saveLog(String content) {
    // 出现异常
    int i = 10 / 0;
    return logMapper.saveLog(content);
}

程序执⾏结果：

⽤户表和⽇志表都没有添加任何数据。

执⾏流程描述：

1.UserController 中调⽤了 UserService 的添加⽅法，UserService 使⽤ NESTED 修饰循环嵌套了 UserController 的事务，并成功执⾏了添加⽅法。

2.UserService 中调⽤了 LogService 的添加⽅法，LogService 使⽤ NESTED 修饰循环嵌套了上⼀个 调⽤类的事务，执⾏了添加⽅法，但在执⾏的过程中出现了异常，回顾当前事务，⽇志添加失败。

3.因为是嵌套事务，所以⽇志添加回顾之后，往上找调⽤它的⽅法和事务回滚了⽤户添加，所以⽤户 添加也失败了，所以最终的结果是⽤户表和⽇志表都没有添加任何数据。

---

嵌套事务（NESTED）和加⼊事务（REQUIRED ）的区别：

• 整个事务如果全部执⾏成功，⼆者的结果是⼀样的。

• 如果事务执⾏到⼀半失败了，那么加⼊事务整个事务会全部回滚；⽽嵌套事务会局部回滚，不会影响上⼀个⽅法中执⾏的结果。

---

先来看嵌套事务 NESTED 示例

示例：使⽤ UserController 调⽤ UserService，UserService 中调⽤ LogService，⽽UserService 和 LogService 中的事务传播特性都是 NESTED，具体实现代码如下。

UserController 实现代码如下：

@RequestMapping("/save")
@Transactional
public Object save(User user) {
    // 插⼊⽤户操作
    userService.save(user);
    return true;
}

UserService 实现代码如下：

@Transactional(propagation = Propagation.NESTED)
public int save(User user) {
    int result = userMapper.save(user);
    System.out.println("执⾏ save ⽅法.");
    // 插⼊⽇志
    logService.saveLog("⽤户插⼊：" + user.getName());
    return result;
}

LogService 实现代码如下：

@Transactional(propagation = Propagation.NESTED)
public int saveLog(String content) {
    // 添加⽇志
    int result = logMapper.saveLog(content);
    try {
        // 出现异常
        int i = 10 / 0;
   } catch (Exception e) {
        // 回滚当前事务
	TransactionAspectSupport.currentTransactionStatus().setRollbackOnly();
   }
    return result;
}

在 LogService 进⾏当前事务的回滚操作，最终执⾏效果是：

• User 表中成功添加数据
• Log 表中没有添加数据

说明：

Log 中的事务已经回滚，但是嵌套事务不会回滚嵌套之前的事务，也就是说嵌套事务可以实现部 分事务回滚

---

加⼊事务 REQUIRED 示例演示

把 NESTED 传播特性改为 REQUIRED

UserController 中的实现代码不变：

@RequestMapping("/save")
@Transactional
public Object save(User user) {
    // 插⼊⽤户操作
    userService.save(user);
    return true;
}

UserService 中的实现代码如下：

@Transactional(propagation = Propagation.REQUIRED)
public int save(User user) {
    int result = userMapper.save(user);
    System.out.println("执⾏ save ⽅法.");
    // 插⼊⽇志
    logService.saveLog("⽤户插⼊：" + user.getName());
    return result;
}

⾸先添加⽤户没有任何问题，⽤户添加成功。

LogService 中的实现代码如下：

@Transactional(propagation = Propagation.REQUIRED)
public int saveLog(String content) {
    // 添加⽇志
    int result = logMapper.saveLog(content);
    try {
        // 出现异常
        int i = 10 / 0;
   } catch (Exception e) {
        // 回滚当前事务  
		TransactionAspectSupport.currentTransactionStatus().setRollbackOnly();
   }
    return result;
}

添加⽇志报错了，将 LogService 中的事务回滚。

最终程序的执⾏结果：

⽤户表和⽇志表中都没有添加任何数据，说明整个事务都回滚了。也就是说 REQUIRED 如果回滚就是 回滚所有事务，不能实现部分事务的回滚。

嵌套事务只所以能够实现部分事务的回滚，是因为事务中有⼀个保存点（savepoint）的概念，嵌套事务 进⼊之后相当于新建了⼀个保存点，⽽滚回时只回滚到当前保存点，因此之前的事务是不受影响的，这 ⼀点可以在 MySQL 的官⽅⽂档汇总找到相应的资料：

MySQL官方文档

⽽ REQUIRED 是加⼊到当前事务中，并没有创建事务的保存点，因此出现了回滚就是整个事务回滚， 这就是嵌套事务和加⼊事务的区别。

嵌套事务（NESTED）和加⼊事务（REQUIRED ）的区别：

• 整个事务如果全部执⾏成功，⼆者的结果是⼀样的。

• 如果事务执⾏到⼀半失败了，那么加⼊事务整个事务会全部回滚；⽽嵌套事务会局部回滚，不会影响上⼀个⽅法中执⾏的结果。

---

总结

Spring 事务使⽤中，重点的内容有 3 个：

1. 在 Spring 项⽬中使⽤事务，⽤两种⽅法⼿动操作和声明式⾃动提交，其中后者使⽤的最多，在⽅法上添加 @Transactional 就可以实现了。

2. 设置事务的隔离级别 @Transactional(isolation = Isolation.SERIALIZABLE)，Spring 中的事务隔离级别有 5 种。

3. 设置事务的传播机制 @Transactional(propagation = Propagation.REQUIRED)，Spring 中的事务传播级别有 7 种。

---