Spring Boot 事务配置管理

原本已收录到我写的10万字Springboot经典学习笔记中，笔记在持续更新……文末有领取方式java

1. 事务相关

场景：咱们在开发企业应用时，因为数据操做在顺序执行的过程当中，线上可能有各类没法预知的问题，任何一步操做都有可能发生异常，异常则会致使后续的操做没法完成。此时因为业务逻辑并未正确的完成，因此在以前操做过数据库的动做并不可靠，须要在这种状况下进行数据的回滚。mysql

事务的做用就是为了保证用户的每个操做都是可靠的，事务中的每一步操做都必须成功执行，只要有发生异常就回退到事务开始未进行操做的状态。这很好理解，转帐、购票等等，必须整个事件流程所有执行完才能人为该事件执行成功，不能转钱转到一半，系统死了，转帐人钱没了，收款人钱还没到。web

事务管理是 Spring Boot 框架中最为经常使用的功能之一，咱们在实际应用开发时，基本上在 service 层处理业务逻辑的时候都要加上事务，固然了，有时候可能因为场景须要，也不用加事务（好比咱们就要往一个表里插数据，相互没有影响，插多少是多少，不能由于某个数据挂了，把以前插的所有回滚）。spring

2. Spring Boot 事务配置

2.1 依赖导入

在 Spring Boot 中使用事务，须要导入 mysql 依赖：sql

<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 配置便可。数据库

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 层，咱们手动抛出个异常来模拟实际中出现的异常，而后观察一下事务有没有回滚，若是数据库中没有新的记录，则说明事务回滚成功。mybatis

@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 调用一下该接口，由于在程序中抛出了个异常，会形成事务回滚，咱们刷新一下数据库，并无增长一条记录，说明事务生效了。事务很简单，咱们平时在使用的时候，通常不会有多少问题，可是并不只仅如此……

3. 常见问题总结

从上面的内容中能够看出，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 的地方加锁，保证锁的范围比事务的范围大便可。

4. 总结

本章主要总结了 Spring Boot 中如何使用事务，只要使用 @Transactional 注解便可使用，很是简单方便。除此以外，重点总结了三个在实际项目中可能遇到的坑点，这很是有意义，由于事务这东西不出问题还好，出了问题比较难以排查，因此总结的这三点注意事项，但愿能帮助到开发中的朋友。

该文已收录到我写的《10万字Springboot经典学习笔记》中，点击下面小卡片，进入【Java开发宝典】，回复：笔记，便可免费获取。

点赞是最大的支持

本文分享自微信公众号 - 武哥聊编程（eson_15）。
若有侵权，请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一块儿分享。