@RequestMapping("/save")
@Transactional(isolation = Isolation.SERIALIZABLE)
public Object save(User user) {
// 插入数据库
int result = userService.save(user);
try {
// 执行了异常代码(0不能做除数)
int i = 10 / 0;
} catch (Exception e) {
System.out.println(e.getMessage());
// 手动回滚事务
TransactionAspectSupport.currentTransactionStatus().setRollbackOnly();
}
return result;
}

2.3.4 @Transactional 工作原理

@Transactional 具体执行细节如下图所示：

三、事务隔离级别

3.1 事务特性回顾

• 原子性：一个事务（transaction）中的所有操作，要么全部完成，要么全部不完成，不会结束在中间某个环节。事务在执行过程中发生错误，会被回滚（Rollback）到事务开始前的状态，就像这个事务从来没有执行过一样。
• 一致性：在事务开始之前和事务结束以后，数据库的完整性没有被破坏。这表示写入的资料必须完全符合所有的预设规则，这包含资料的精确度、串联性以及后续数据库可以自发性地完成预定的工作。
• 持久性：事务处理结束后，对数据的修改就是永久的，即便系统故障也不会丢失。
• 隔离性：数据库允许多个并发事务同时对其数据进行读写和修改的能力，隔离性可以防止多个事务并发执行时由于交叉执行而导致数据的不一致。事务隔离分为不同级别，包括读未提交（Read uncommitted）、读提交（read committed）、可重复读（repeatable read）和串行化 （Serializable）。

• 原子性（Atomicity，或称不可分割性）
• 一致性（Consistency）
• 隔离性（Isolation，又称独立性）
• 持久性（Durability）。

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

什么是可控呢？

3.2 Spring 中设置事务隔离级别

3.2.1 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 的执行结果如下：

3.2.2 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 事务传播机制

4.1 事务传播机制是什么？

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

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

事务隔离级别是保证多个并发事务执行的可控性的（稳定性的），而 事务传播机制是保证一个事务在多 个调用方法间的可控性的（稳定性的） 。

例子：像新冠病毒一样，它有不同的隔离方式（酒店隔离还是居家隔离），是为了保证疫情可控，

然而在每个人的隔离过程中，会有很多个执行的环节，比如酒店隔离，需要负责人员运送、物品运

送、消杀原生活区域、定时核算检查和定时送餐等很多环节，而事务传播机制就是保证一个事务在

传递过程中是可靠性的，回到本身案例中就是保证每个人在隔离的过程中可控的。

事务隔离级别解决的是多个事务同时调用一个数据库的问题，如下图所示：

而事务传播机制解决的是一个事务在多个节点（方法）中传递的问题，如下图所示：

4.3 事务传播机制有哪些？

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 类：

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

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

4.4.1 支持当前事务（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 中的用户插入方法也回滚了。

4.4.2 不支持当前事务（REQUIRES_NEW）

UserController 类中的代码不变，将添加用户和添加日志的方法修改为 REQUIRES_NEW 不支持当前事 务，重新创建事务，观察执行结果：

@RequestMapping("/save")
@Transactional
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.REQUIRES_NEW)
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.REQUIRES_NEW)
public int saveLog(String content) {
// 出现异常
int i = 10 / 0;
return logMapper.saveLog(content);
}
}

程序执行结果： User 表中成功插入了数据， Log 表执行失败，但没影响 UserController 中的事务。

4.4.3 不支持当前事务，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);
}

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

4.4.4 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. 因为是嵌套事务，所以日志添加回顾之后，往上找调用它的方法和事务回滚了用户添加，所以用户添加也失败了，所以最终的结果是用户表和日志表都没有添加任何数据。

4.4.5 嵌套事务和加入事务有什么区别？

先来看嵌套事务 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 的官方文档汇总找到相应的资料：

https://dev.mysql.com/doc/refman/5.7/en/savepoint.html

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

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

整个事务如果全部执行成功，二者的结果是一样的。

如果事务执行到一半失败了，那么加入事务整个事务会全部回滚；而嵌套事务会局部回滚，不会影

响上一个方法中执行的结果。

总结

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

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

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

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