企业应用中的数据操作在顺序执行的过程中，往往存在各种无法预知的问题。任何一步操作都有可能发生异常，而异常则会导致后续的操作无法完成。业务逻辑没有正确完成，之前操作数据库的动作也就不可靠，这种情况下，我们需要进行数据的回滚。
事务的作用就是保证用户的每一个操作都是可靠的，保证事务中的每一步操作都可成功执行。只要有异常发生，数据便会回退到事务进行任务操作之前的状态。这很好理解，比如转账、购票等业务，只有整个业务流程全部执行完毕才能认为相应事件执行成功，不能钱转到一半，或票款刚付出去，结果系统死了，导致付款人钱没了，而收款人也没能收到这笔钱。
事务管理是 Spring Boot 框架中最为常用的功能之一，实际应用开发时，我们基本上都会在 Service 层处理业务逻辑时加上事务。当然了，有时候由于场景的需要，也可不加事务，比如往一个表里插入数据，数据之间互不影响，这时不能因为某条数据挂了，而把之前插入的数据全部回滚。
11.1 Spring Boot 事务配置
接下来，带大家具体了解下 Spring Boot 事务的配置过程，主要包括依赖注入、事务测试两大步骤。
11.1.1 依赖导入
在 Spring Boot 中使用事务，需要导入 MySQL 依赖：
<dependency>
<groupId>org.mybatis.spring.boot</groupId>
<artifactId>mybatis-spring-boot-starter</artifactId>
<version>1.3.2</version>
</dependency>
导入了 MySQL 依赖后，Spring Boot 会自动注入 DataSourceTransactionManager，我们不需要其他的任何配置，就可以通过注解 @Transactional 使用事务。关于 MyBatis 的配置，上一篇中已经做了说明，这里使用上一篇中介绍的 MyBatis 配置即可。
11.1.2 事务测试
我们首先在数据库表中插入一条数据：
然后，我们写一个插入 mapper ：
public interface UserMapper {
@Insert("insert into user (user_name, password) values (#{username}, #{password})")
Integer insertUser(User user);
}
OK，接下来我们测试一下 Spring Boot 中的事务处理，在 Service 层，我们手动抛出一个异常，来模拟实际中出现的异常。然后，观察一下事务有没有回滚，如果数据库中没有新的记录，则说明事务回滚成功。手动抛出异常的代码如下所示：
@Service
public class UserServiceImpl implements UserService {
@Resource
private UserMapper userMapper;
@Override
@Transactional
public void isertUser(User user) {
// 插入用户信息
userMapper.insertUser(user);
// 手动抛出异常
throw new RuntimeException();
}
}
我们来测试一下：
@RestController
public class TestController {
@Resource
private UserService userService;
@PostMapping("/adduser")
public String addUser(@RequestBody User user) throws Exception {
if (null != user) {
userService.isertUser(user);
return "success";
} else {
return "false";
}
}
}
我们使用 Postman 调用该接口，而程序中抛出的异常，会造成事务回滚。我们刷新一下数据库，发现并没有新增的记录，说明事务生效了。
事务很简单，我们平时使用时，一般也很少出问题，但事实上似乎并非如此……
11.2 常见问题总结
从上面的解析可以看出，在 Spring Boot 中使用事务非常简单，一个 @Transactional 注解即可解决问题。话虽如此，但在实际项目中，却有很多小坑在等着我们，这些小坑是我们写代码时不曾注意到的，而且在正常情况下也很难发现它们。可随着项目的扩大，它们一旦引发问题，又是很难排查到的。
这一节，我专门针对实际项目中经常出现的、和事务相关的技术细节做个总结，希望读者读完之后，能够落实到自己的项目中，有所受益。
11.2.1 异常并没有被“捕获”到
首要说的是，异常没有被“捕获”到，而导致事务没有回滚。
我们在编写业务层代码时，或许已经考虑到了异常的存在，也或者编辑器已经提示我们需要抛出异常，但有一点需要注意：并不是说我们把异常抛出来，有了异常事务就会回滚。
@Service
public class UserServiceImpl implements UserService {
@Resource
private UserMapper userMapper;
@Override
@Transactional
public void isertUser2(User user) throws Exception {
// 插入用户信息
userMapper.insertUser(user);
// 手动抛出异常
throw new SQLException("数据库异常");
}
}
我们看上面这段代码，其实并没有什么问题，手动抛出一个 SQLException 来模拟实际运行中操作数据库发生的异常。在这个方法中，既然抛出了异常，那么事务应该回滚，实际并非如此。读者可以使用我源码中 Controller 接口，通过 Postman 测试一下，就会发现，仍然插入了一条用户数据。
问题出在哪呢？这是因为 Spring Boot 默认的事务规则是遇到运行异常（RuntimeException）和程序错误（Error）才会回滚。比如上面例子中抛出的 RuntimeException，可完成回滚，而抛出 SQLException，则无法回滚。针对非检测异常，如果要进行事务回滚，可以在 @Transactional 注解中使用 rollbackFor 属性指定异常，比如 @Transactional(rollbackFor = Exception.class)，这样就没有问题了。这也在告诉我们，实际项目开发中，一定要指定异常。
11.2.2 异常被“吃”掉
这个标题很搞笑，异常怎么会被吃掉呢？还是回归到现实项目中，我们在处理异常时，有两种方式，要么抛出去，让上一层来捕获处理；要么把异常“try catch”掉，在异常出现的地方进行处理。而正是这个 try…catch，导致异常被“吃”掉，事务无法回滚。我们还是看上面那个例子，简单修改一下代码：
@Service
public class UserServiceImpl implements UserService {
@Resource
private UserMapper userMapper;
@Override
@Transactional(rollbackFor = Exception.class)
public void isertUser3(User user) {
try {
// 插入用户信息
userMapper.insertUser(user);
// 手动抛出异常
throw new SQLException("数据库异常");
} catch (Exception e) {
// 异常处理逻辑
}
}
}
读者可以使用我源码中 Controller 接口，通过 Postman 测试一下，就会发现，仍然可以插入一条用户数据，这就说明事务并没有因为抛出异常而回滚。
这个细节往往比上面那个坑更难以发现，因为我们的开发思维很容易导致 try…catch 代码的产生，一旦出现这种问题，排查起来往往比较费劲。所以在平时写代码时，一定要多思考，多注意这种细节，尽量避免给自己挖坑。
那面对该问题怎么解决呢？直接往上抛，给上一层处理即可，千万不要在事务中把异常自己“吃”掉。
11.2.3 事务范围
事务范围这个坑，比上面两个坑埋得都要深！我曾在实际项目中遇到过这种情况，实际场景在本课中就不模拟了，我写了一个 Demo，大家可以看下。把这个坑记住即可，以后写代码遇到并发问题时，能注意到这个坑，那么这节课也就有价值了。
我写的 Demo，如下所示：
@Service
public class UserServiceImpl implements UserService {
@Resource
private UserMapper userMapper;
@Override
@Transactional(rollbackFor = Exception.class)
public synchronized void isertUser4(User user) {
// 实际中的具体业务……
userMapper.insertUser(user);
}
}
从上面代码可以看到，因为要考虑并发问题，我在业务层代码的方法上加了个 synchronized 关键字。
我先举个实际场景中的例子，比如一个数据库中，针对某个用户，只有一条记录，下一个插入动作过来，会先判断该数据库中有没有相同的用户，如果有就不插入，而是更新，如果没有才会插入。理论上，数据库中一个用户永远只有一条用户信息，不会出现同一数据库中插入了两条相同用户的信息。
但在压力测试时，就会出现上面问题。数据库中确实有两条同一用户的信息，分析其原因，问题出在了事务的范围和锁的范围上。
从上面方法中可以看到，方法上加了事务，也就意味着，该方法开始执行时，事务启动，执行完了后，事务关闭。但 synchronized 并没有起作用，根本原因是事务的范围比锁的范围大。也就是说，在加锁的那部分代码执行完之后，锁释放掉了，但是事务还没结束。此时如果另一个线程进来，数据库的状态和第一个线程刚进来时是一样的。即由于 MySQL Innodb 引擎的默认隔离级别是可重复读（在同一个事务里，Select 的结果是事务开始时时间点的状态）的，线程二事务开始的时候，线程一还没提交完成，导致读取的数据还没更新。第二个线程也做了插入动作，从而导致了脏数据。
这个问题可以避免，第一，把事务去掉即可（不推荐）；第二，在调用该 Service 的地方加锁，保证锁的范围比事务的范围大即可。