Spring Boot事务配置管理

Spring Boot 事务配置
2.1 依赖导入
在 Spring Boot 中使用事务，需要导入 mysql 依赖：

org.mybatis.spring.boot
mybatis-spring-boot-starter
1.3.2

导入了 mysql 依赖后，Spring Boot 会自动注入 DataSourceTransactionManager，我们不需要任何其他的配置就可以用 @Transactional 注解进行事务的使用。关于 mybatis 的配置，在上一节课中已经说明了，这里还是使用上一节课中的 mybatis 配置即可。
2.2 事务的测试
我们首先在数据库表中插入一条数据：
id user_name password
1 倪升武 123456
然后我们写一个插入的 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 调用一下该接口，因为在程序中抛出了个异常，会造成事务回滚，我们刷新一下数据库，并没有增加一条记录，说明事务生效了。事务很简单，我们平时在使用的时候，一般不会有多少问题，但是并不仅仅如此……

常见问题总结
从上面的内容中可以看出，Spring Boot 中使用事务非常简单，@Transactional 注解即可解决问题，说是这么说，但是在实际项目中，是有很多小坑在等着我们，这些小坑是我们在写代码的时候没有注意到，而且正常情况下不容易发现这些小坑，等项目写大了，某一天突然出问题了，排查问题非常困难，到时候肯定是抓瞎，需要费很大的精力去排查问题。
这一小节，我专门针对实际项目中经常出现的，和事务相关的细节做一下总结，希望读者在读完之后，能够落实到自己的项目中，能有所受益。
3.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)，这样就没有问题了，所以在实际项目中，一定要指定异常。
3.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 代码的产生，一旦出现这种问题，往往排查起来比较费劲，所以我们平时在写代码时，一定要多思考，多注意这种细节，尽量避免给自己埋坑。
那这种怎么解决呢？直接往上抛，给上一层来处理即可，千万不要在事务中把异常自己 ”吃“ 掉。
3.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 的地方加锁，保证锁的范围比事务的范围大即可。