@Transactional详解

ゝ一世哀愁。 2024-03-16 14:55 62阅读 0赞

Spring 事务的两种使用方式：声明式事务和编程式事务，以及其使用误区和最佳实践。Spring 事务管理的核心就是 @Transactional 注解，它可以用于类或方法级别，用于将方法调用批量提交到数据库中。

### Spring 5.0版本中 @Transactional 注解提供了以下参数 ###

<table> 
 <thead> 
  <tr> 
   <th>参数</th> 
   <th>参数意义</th> 
   <th>默认值</th> 
   <th>可选值</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>value 或 transactionManager</td> 
   <td>指定使用哪个事务管理器</td> 
   <td>""</td> 
   <td>已配置的事务管理器的 bean 名称</td> 
  </tr> 
  <tr> 
   <td>propagation</td> 
   <td>指定事务的传播机制</td> 
   <td>REQUIRED</td> 
   <td>REQUIRED、SUPPORTS、MANDATORY、REQUIRES_NEW、NOT_SUPPORTED、NEVER、NESTED</td> 
  </tr> 
  <tr> 
   <td>isolation</td> 
   <td>指定事务的隔离级别</td> 
   <td>DEFAULT</td> 
   <td>DEFAULT、READ_UNCOMMITTED、READ_COMMITTED、REPEATABLE_READ、SERIALIZABLE</td> 
  </tr> 
  <tr> 
   <td>readOnly</td> 
   <td>指定事务是否为只读事务</td> 
   <td>false</td> 
   <td>true 或 false</td> 
  </tr> 
  <tr> 
   <td>timeout</td> 
   <td>指定事务的超时时间，以秒为单位</td> 
   <td>-1</td> 
   <td>正整数</td> 
  </tr> 
  <tr> 
   <td>rollbackFor</td> 
   <td>指定需要回滚事务的异常类型</td> 
   <td>空数组</td> 
   <td>异常类型</td> 
  </tr> 
  <tr> 
   <td>noRollbackFor</td> 
   <td>指定不需要回滚事务的异常类型</td> 
   <td>空数组</td> 
   <td>异常类型</td> 
  </tr> 
  <tr> 
   <td>rollbackForClassName</td> 
   <td>与 rollbackFor 相同，只不过是用字符串形式指定异常类型</td> 
   <td>""</td> 
   <td>异常类型的字符串表示</td> 
  </tr> 
  <tr> 
   <td>noRollbackForClassName</td> 
   <td>与 noRollbackFor 相同，只不过是用字符串形式指定异常类型</td> 
   <td>""</td> 
   <td>异常类型的字符串表示</td> 
  </tr> 
 </tbody> 
</table>

###  ###

### 作用范围 ###

@Transactional 可以标记在方法上，也可以标记在接口、类或类上的方法上。当 @Transactional 标注在类上时，该类所有非 private 的方法都具有事务性。

### 传播机制 ###

@Transactional 的传播机制是指一个带有事务性质的方法被另外一个方法调用时，当前方法如何使用事务。Spring 提供了多种传播行为，如：

1.  REQUIRED：如果当前存在事务，则加入该事务；否则，新建一个事务。
2.  SUPPORTS：支持当前事务，如果当前没有事务，则不使用事务。
3.  MANDATORY：强制使用当前事务，如果当前没有事务，则抛出异常。
4.  REQUIRES\_NEW：如果当前存在事务，则挂起该事务，并开启一个新的事务，直到新事务完成；然后恢复之前的事务。
5.  NOT\_SUPPORTED：以非事务方式运行，如果当前存在事务，则挂起该事务。
6.  NEVER：以非事务方式运行，如果当前存在事务，则抛出异常。
7.  NESTED：如果当前存在事务，则嵌套事务执行；否则和 REQUIRED 同样处理。

### 回滚规则 ###

一个事务执行过程中，如果出现异常，那么事务会回滚。以下是回滚规则：

1.  @Transactional 注解的默认回滚行为对 unchecked 异常（RuntimeException 及其子类）进行回滚。
2.  对于 checked 异常，@Transactional 注解默认不回滚。
3.  可以使用 rollbackFor 属性来制定需要回滚的异常类型，如：@Transactional(rollbackFor = Exception.class)。
4.  noRollbackFor 属性可以指定哪些异常不需要回滚。

### 事务隔离级别 ###

@Transactional 的隔离级别是指多个事务同时执行时，一个事务所读取的数据被其他事务修改的情况下，该事务所采用的处理方式。Spring 支持五种隔离级别，分别是：

1.  DEFAULT：使用数据库默认的隔离级别。
2.  READ\_UNCOMMITTED：低级别隔离，允许脏读、幻读和不可重复读。
3.  READ\_COMMITTED：只能读取已提交的数据，避免了脏读问题；但可能出现幻读和不可重复读。
4.  REPEATABLE\_READ：保证了一个事务内，多次读取同样的数据结果相同，避免了幻读问题。
5.  SERIALIZABLE：最高级别的隔离，将事务串行化执行，性能最低，但可以避免所有的并发问题。

### 超时设置 ###

@Transactional 中 timeout 属性用于指定事务执行的超时时间（单位为秒），如果方法执行时间超出该值，则自动回滚事务。

### @Transactional播机制的使用示例 ###

@Service
    @Transactional
    public class UserServiceImpl implements UserService {
    
        @Autowired
        private UserDao userDao;
    
        @Override
        public void updateUser(User user){
            userDao.update(user);
            try {
                // 模拟业务异常
                int result = 1/0;
            } catch (Exception e) {
                e.printStackTrace();
            }
        }
    
        @Override
        @Transactional(propagation = Propagation.REQUIRES_NEW)
        public void addUser(User user){
            userDao.insert(user);
        }
    
        @Override
        @Transactional(propagation = Propagation.NOT_SUPPORTED)
        public void getUserById(int id){
            userDao.selectById(id);
        }
    }

在上述示例中，我们定义了一个名为`UserServiceImpl`的服务，它使用了@Transactional注解指定了默认的传播行为，并且使用了其他不同的传播行为。

在`updateUser()`方法中，我们没有指定传播行为，因此其将使用默认的传播行为REQUIRE。在该方法中，我们做了一个业务操作并进行了异常处理，模拟了一个异常情况。由于默认传播行为下，方法会加入当前事务，因此在出现异常时，事务将进行回滚，以保证数据的一致性和完整性。

在`addUser()`方法中，我们使用了REQUIRES\_NEW传播行为创建了一个新的事务。在该方法中，我们执行了一个插入操作，因为这个操作需要在一个独立的事务中执行而不受外面事务的影响，所以我们选择使用了REQUIRES\_NEW传播行为。

在`getUserById()`方法中，我们使用了NOT\_SUPPORTED传播行为。在该方法中，我们执行了一个查询操作，并且由于该方法并不需要事务支持，因此我们选择使用了NOT\_SUPPORTED传播行为以非事务方式执行操作，以避免无谓的事务开销和死锁等问题。

### @Transactional回滚规则的使用示例 ###

@Service
    @Transactional
    public class UserServiceImpl implements UserService {
    
        @Autowired
        private UserDao userDao;
    
        @Override
        public void updateUser(User user){
            userDao.update(user);
            try {
                // 模拟业务异常
                int result = 1/0;
            } catch (Exception e) {
                // 回滚事务
                TransactionAspectSupport.currentTransactionStatus().setRollbackOnly();
                e.printStackTrace();
            }
        }
    
        @Override
        @Transactional(propagation = Propagation.REQUIRES_NEW, rollbackFor = RuntimeException.class)
        public void addUser(User user){
            userDao.insert(user);
        }
    
        @Override
        @Transactional(noRollbackFor = {CustomException.class})
        public void getUserById(int id) throws CustomException {
            User user = userDao.selectById(id);
            if(user == null){
                throw new CustomException("用户不存在");
            }
        }
    }

在上述示例中，我们定义了一个名为`UserServiceImpl`的服务，它使用了@Transactional注解进行事务管理，并且使用了不同的回滚规则。

在`updateUser()`方法中，我们没有指定回滚规则，但是由于在方法中捕获了RuntimeException异常并手动设置了回滚标志，因此当该方法执行时，即使默认的回滚规则只针对RuntimeException异常生效，它也会被回滚。

在`addUser()`方法中，我们使用了REQUIRES\_NEW传播机制创建了一个新的事务，并且指定了rollbackFor属性，用于指定此方法抛出指定类型的异常时，回滚事务。在此示例中，我们指定了RuntimeException.class。

在`getUserById()`方法中，我们使用了NO\_ROLLBACK\_FOR传播机制，用于指定不回滚指定类型的异常。在本示例中，我们定义了一个CustomException类，并指定当该类异常被抛出时不回滚事务。

### @Transactional事务隔离级别使用示例 ###

@Service
    @Transactional(isolation = Isolation.READ_COMMITTED)
    public class UserServiceImpl implements UserService {
    
        @Autowired
        private UserDao userDao;
    
        @Override
        public void updateUser(User user){
            userDao.update(user);
        }
    
        @Override
        @Transactional(isolation = Isolation.REPEATABLE_READ)
        public void addUser(User user){
            userDao.insert(user);
        }
    
        @Override
        @Transactional(isolation = Isolation.SERIALIZABLE)
        public void getUserById(int id){
            userDao.selectById(id);
        }
    }

在上述示例中，我们定义了一个名为`UserServiceImpl`的服务，它使用了@Transactional注解指定了默认的事务隔离级别为READ\_COMMITTED，并且在其他方法中使用了不同的事务隔离级别。

在`updateUser()`方法中，我们没有指定事务隔离级别，因此它将使用默认的READ\_COMMITTED级别。在该方法中，我们执行了一个更新操作，事务即时提交。

在`addUser()`方法中，我们使用了REPEATABLE\_READ事务隔离级别，以确保在插入操作期间读取到的数据一直保持一致性。如果另一个事务已经对数据进行了修改，该操作将会被阻塞，直到前一事务完成。

在`getUserById()`方法中，我们使用了SERIALIZABLE事务隔离级别，以确保在查询操作期间数据一直保持一致性。如果其他的事务对表的数据进行了修改，该方法将被阻塞，直到其他的事务提交完成或回滚为止。

根据具体业务场景，灵活选择合适的事务隔离级别可以提高系统性能和数据一致性，但是过高的隔离级别也会带来并发性能的下降。需要根据实际情况进行权衡和选择。

### @Transactional声明式事务不生效的几种情况 ###

事务不生效问题经常出现在我们使用 Spring 声明式事务中，主要原因是因为对 Spring 事务管理机制和 声明式事务实现原理不够了解所致，下面我们一起来看下常见误区：

#### 1：类内部访问 ####

*  **场景描述**：

A 类的 a1 方法没有标注 @Transactional，a2 方法标注 @Transactional，在 a1里面调用 a2；事务不生效。

*  **举例说明：**

@Service
    public class TestService {
    
        public void test(){
            insert();
        }
    
        @Transactional(rollbackFor = Exception.class)
        public void insert(){
            // 数据库操作
        }
    }

在test() 方法中调用被 @Transaction 注解标注的 insert()方法

@RestController
    public class TestController {
    
        @Resource
        private TestService testService;
    
        @GetMapping("/test")
        public void test() {
            testService.test();
        }
    }

当进行调用 **testService**.test() 时，insert() 方法的事务不会生效。

*  **原因解释：**

因为 @Transactional 的工作机制是基于 AOP 实现，AOP 是使用动态代理实现的。如果通过代理调用insert()，通过 AOP 会前后进行增强，增强的逻辑其实就是在 insert() 的前后别加上开启、提交事务的逻辑。

而现在是在 test() 方法中直接调用 this.insert(),this 指向 TestService 的非代理对象,不会经过 AOP 的事务增强操作。也就是类内部调用事务方法，不会通过代理方式访问。

解决方法也很简单，这里介绍一个通用的处理方式，那就是在 本类中获取 Spring IoC 容器，使用依赖查找的方式从容器中直接获取 当前代理对象。如下：

@Service
    public class TestService implements ApplicationContextAware {
    
        private ApplicationContext applicationContext;
        
        @Override
        public void setApplicationContext(ApplicationContext applicationContext) throws BeansException {
            this.applicationContext = applicationContext;
        }
        
        public void test() {
            // 从Spring IoC 容器中获取代理类
            TestService testService = applicationContext.getBean(TestService.class);
            // 调用代理类目标方法
            testService.insert();
        }
    
        @Transactional(rollbackFor = Exception.class)
        public void insert() {
            // 数据库操作
            System.out.println("insert 数据库操作。。。");
        }
    }

除了上述方法，我们还可以 通过 AopContext 获取代理对象来调用：

@Service
    public class TestService {
        
        public void test() {        
           // 获取当前类的代理对象
           TestService testServiceProxy = ((TestService)AopContext.currentProxy())
            // 调用代理类目标方法
           testServiceProxy.insert();
        }
    
        @Transactional(rollbackFor = Exception.class)
        public void insert() {
            // 数据库操作
            System.out.println("insert 数据库操作。。。");
        }
    }

注意启动类需要添加 @EnableAspectJAutoProxy(exposeProxy = true) 注解

#### 2：非 public 可重载方法 ####

*  **场景描述**：

在 Spring Bean 的非 public 方法上，添加 @Transactional 注解不会生效。

*  **举例说明：**

@Service
    public class TestService {
        
        @Transactional(rollbackFor = Exception.class)
        protected void insert1(){
            // 数据库操作
        }
    
        @Transactional(rollbackFor = Exception.class)
        public final void insert2(){
            // 数据库操作
        }
    
        @Transactional(rollbackFor = Exception.class)
        public static void insert3(){
            // 数据库操作
        }
    }

**insert1**() 被 protected 修饰符修饰，导致事务不会生效； insert2() 被 final 修饰，导致事务不生效； insert3() 被 static 修饰，导致事务不会生效。

@RestController
    public class TestController {
    
        @Resource
        private TestService testService;
    
        @GetMapping("/test")
        public void test() {
            testService.insert1();
            testService.insert2();
            testService.insert3();
        }
    }

实际使用时，这三种场景不太容易出现，因为 IDEA 会有提醒: 被 @Transactional 标注的方法必须可被重载。

![c1c854b62b988fdbd21aed0a5922ac50.png][]

*  **原因解释：**

Spring 要求被代理方法必须是 public 的并且是可被重载的。

#### 3：异常不匹配(重点) ####

*  **场景描述**：

@Transactional 没有设置 rollbackFor = Exception.class 属性或者指定异常类型和方法抛出的异常类型不匹配。

*  **举例说明：**

@Service
    public class TestService {
    
        @Transactional
        public void insert() throws Exception {
            // 数据库操作
            throw new Exception("发生异常");
        }
    }

*  **原因解释：**

Spring 事务默认只捕获 uncheck exception，即只会回滚 RuntimeException（运行时异常）和Error（错误），对于普通的 Exception（非运行时异常），它不会回滚。

![34184fbd86d98ebc3fc09222935e8712.png][]

#### 4：多线程 ####

*  **场景描述**：

在 Spring 事务方法中开启线程操作数据库，不受主线程事务控制。

*  **举例说明：**

@Transactional(rollbackFor = Exception.class)
        public void insert() {
            //  开启子线程
            new Thread(() -> {
               doDb();
            }).start();
    
            // 主线程异常
            throw new RuntimeException("父线程异常");
        }

父线程抛出线程，事务回滚。因为子线程是独立存在，和父线程不在同一个事务中，所以子线程的修改并不会被回滚。

@Transactional(rollbackFor = Exception.class)
        public void insert2() {
    
            //  开启子线程
            new Thread(() -> {
                doDb();
                throw new RuntimeException("子线程异常");
            }).start();
        }

由于子线程的异常不会被外部的线程捕获，所以父线程不抛异常，事务回滚没有生效。

*  **原因解释：**

Spring事务控制是通过 AOP 动态代理，在方法开始是开启一个事务，并把该事务放在当前前程上下文中进行传递，开启子线程事务无法传递，导致子线程事务失效。

#### 5：嵌套事务未捕获异常 ####

Spring 传播属性中的嵌套事务是通过 JDBC 提供 SavePoint 来实现的。

--------------------

PROPAGATION\_REQUIRES\_NEW 和 PROPAGATION\_NESTED 比较容易混淆：

**PROPAGATION\_REQUIRES\_NEW**：启动一个新的, 不依赖于环境的 “内部” 事务. 这个事务将被完全 commited 或 rolled back 而不依赖于外部事务, 它拥有自己的隔离范围, 自己的锁, 等等. 当内部事务开始执行时, 外部事务将被挂起, 内务事务结束时, 外部事务将继续执行。

**PROPAGATION\_NESTED**： 开始一个 “嵌套的” 事务, 它是已经存在事务的一个真正的子事务.潜套事务开始执行时, 它将取得一个 savepoint. 如果这个嵌套事务失败, 我们将回滚到此savepoint. 嵌套事务是外部事务的一部分, 只有外部事务结束后它才会被提交。**如果外部事务 commit, 嵌套事务也会被 commit, 这个规则同样适用于 rollback**。

--------------------

*  **场景描述**：

一个事务方法A调用另一个嵌套事务方法B，嵌套事务方法A 异常，不希望影响 事务方法B

*  **举例说明：**

public class TestService {
    
        @Resource
        private TagRepository tagRepository;
    
         // 默认隔离级别
        @Transactional(propagation = Propagation.REQUIRED)
        public void insert1() {
            tagRepository.upsert("insert1", TagType.UNKNOWN);
            ((TestService) AopContext.currentProxy()).insert2();
        }
    
        @Transactional(propagation = Propagation.NESTED, rollbackFor = RuntimeException.class)
        public void insert2() {
            tagRepository.upsert("insert2", TagType.UNKNOWN);
              throw new RuntimeException("insert2 exception");
        }
    }

这种情况使用了嵌套的内部事务，原本是希望调用 insert2()方法时，如果出现了异常，只回滚insert2()方法里的内容，不回滚 insert1里的内容，即回滚保存点。但实际上，insert1 也回滚了。

*  **原因解释：**

因为insert2方法出现了异常，没有手动捕获，会继续往上抛，到外层 insert2 方法的代理方法中捕获了异常。所以，这种情况是直接回滚了整个事务，不只回滚单个保存点。

可以将内部嵌套事务放在 try/catch 中，并且不继续往上抛异常。这样就能保证，如果内部嵌套事务中出现异常，只回滚内部事务，而不影响外部事务。

// 默认隔离级别
        @Transactional(propagation = Propagation.REQUIRED)
        public void insert1() {
            tagRepository.upsert("insert1", TagType.UNKNOWN);
            try {
                ((TestService) AopContext.currentProxy()).insert2();
            } catch (Exception e) {
                System.out.println("捕获 insert2 异常");
            }
        }

--------------------

这种方式也是嵌套事务最有价值的地方, 它起到了分支执行的效果。嵌套事务执行异常，自动回滚到保存点，在外部事务捕获异常，做其他逻辑处理。

#### 6：自己吞掉了异常 ####

*  **场景描述**：

在事务方法中 try…catch 住异常没有向外抛出，导致事务不生效。

*  **举例说明：**

@Transactional
        protected void test(){
            // 数据库操作
            try {
                doOther();
            } catch (Exception e) {
                log.error("xxx");
            }
        }

*  **原因解释：**

Spring 事物处理是通过 AOP try…catch 代理方法,根据异常信息来回滚事物的,如果没检测到异常,也便不会回滚事物了。

### @Transactional声明式事务的大事务问题及如何避免大事务 ###

@Transactional注解一般加在某个业务方法上，会导致整个业务方法都在同一个事务中，粒度太粗，不好控制事务范围，是出现大事务问题的最常见的原因。

**大事务常见问题**

所谓大事务就是事务流程较长的事务，大事务会造成许多性能问题：

*  死锁
 *  锁定太多的数据，造成大量的阻塞和锁超时
 *  执行时间长，容易造成主从延迟
 *  回滚时间长
 *  并发情况下，数据库连接池容易被占满
 *  undo log日志膨胀，不仅增加了存储的空间，而且可能降低查询的性能

最主要的影响数据库连接池容易被撑爆，导致大量线程等待，造成请求无响应或请求超时。

如何查询大事务？

select * from information_schema.innodb_trx where TIME_TO_SEC(timediff(now(),trx_started))>10

#### **1.少用 @Transactional 注解** ####

@Transactional注解一般加在某个业务方法上，会导致整个业务方法都在同一个事务中，粒度太粗，不好控制事务范围，是出现大事务问题的最常见的原因。可以使用我们上面介绍到的编程式事务，在spring项目中使用 TransactionTemplate 手动执行事务。

#### **2. 将查询方法放到事务外** ####

如果出现大事务，可以将查询(select)方法放到事务外，也是比较常用的做法，因为一般情况下这类方法是不需要事务的。如下面代码：

@Transactional(rollbackFor=Exception.class) 
       public void save(User user) { 
             queryData1(); 
             queryData2(); 
             addData1(); 
             updateData2(); 
       }

可以将queryData1和queryData2两个查询方法放在事务外执行，将真正需要事务执行的代码才放到事务中，比如：addData1和updateData2方法，这样就能有效的减少事务的粒度。

该怎么拆分呢? 多数人可能会想到下面这样：

public void save(User user) { 
             queryData1(); 
             queryData2(); 
             doSave(); 
        } 
        
        @Transactional(rollbackFor=Exception.class) 
        public void doSave(User user) { 
           addData1(); 
           updateData2(); 
        }

这个例子是非常经典的错误，这种直接方法调用的做法事务不会生效，这和我们前面在 Spring 事务不生效一章中介绍的第一种情况一模一样，这种错误经常会在日常开发中出现。即使有经验的开发人员稍不注意，就会采坑。

因此，更推荐使用下面方法重构实现：

@Resource
       private TransactionTemplate transactionTemplate; 
        
       public void save(final User user) { 
             queryData1(); 
             queryData2(); 
             transactionTemplate.execute(new TransactionCallbackWithoutResult() {
                @Override
                protected void doInTransactionWithoutResult(TransactionStatus transactionStatus) {
                    try {
                        //业务代码
                        addData1(); 
                        updateData2(); 
                    } catch (Exception e){
                        //回滚
                        transactionStatus.setRollbackOnly();
                    }
                }
            });
       }

#### **3. 事务中避免远程调用** ####

我们在接口中调用其他系统的接口是不能避免的，由于网络不稳定，这种远程调的响应时间可能比较长，如果远程调用的代码放在某个事务中，这个事务就可能是大事务。当然，远程调用不仅仅是指调用接口，还有包括：发MQ消息，或者连接redis、mongodb保存数据等。

@Transactional(rollbackFor=Exception.class) 
       public void save(User user) { 
             callRemoteApi(); 
             addData1();
             sendMq(); 
       }

远程调用的代码可能耗时较长，切记一定要放在事务之外。

@Resource
       private TransactionTemplate transactionTemplate; 
        
       public void save(User user) { 
             callRemoteApi(); 
             transactionTemplate.execute(new TransactionCallbackWithoutResult() {
                @Override
                protected void doInTransactionWithoutResult(TransactionStatus transactionStatus) {
                    try {
                        //业务代码
                        addData1();
                    } catch (Exception e){
                        //回滚
                        transactionStatus.setRollbackOnly();
                    }
                }
            });
             sendMq();
       }

有些朋友可能会问，远程调用的代码不放在事务中如何保证数据一致性呢?这就需要建立：重试+补偿机制，达到数据最终一致性了。

#### **4. 事务中避免一次性处理太多数据** ####

如果一个事务中需要处理的数据太多，也会造成大事务问题。比如为了操作方便，你可能会一次批量更新1000条数据，这样会导致大量数据锁等待，特别在高并发的系统中问题尤为明显。

@Transactional(rollbackFor = Exception.class)
        public void saveList(List<User> userList) {
            insert(userList);
        }

解决办法是分页处理，1000条数据，分50页，一次只处理20条数据，这样可以大大减少大事务的出现。

public void saveList(List<User> userList) {
            Lists.partition(userList, 20)
                    .forEach(users -> {
                        transactionTemplate.execute(transactionStatus -> {
                            return insert(users);
                        });
                    });
        }

### Spring5.0@Transactional底层实现原理 ###

[Spring事务的底层实现流程图][Spring]

Spring 5.0 中 @Transactional 注解的底层实现原理主要依赖于 AOP（面向切面编程） 和事务管理器。

当一个方法被 @Transactional 注解标记时，Spring 会通过 AOP 动态代理创建一个代理对象，该对象拦截了方法的调用，并在方法执行前后启动和提交/回滚事务。而事务管理器则是负责协同 Spring 和底层数据库连接资源，来确保事务完成性与一致性。

具体来说，@Transactional 注解通过 AOP 实现，主要分为以下三个步骤：

1.  扫描注解：Spring 在启动时扫描所有带有 @Transactional 注解的类和方法。
2.  创建代理对象：对于 @Transactional 注解标记的方法，使用 JDK 代理或 CGLIB 创建一个 AOP 代理对象。
3.  织入逻辑：将事务管理器的逻辑代码和 AOP 代理对象织入到目标方法中，在方法开始之前开启事务，在方法正常结束后提交事务，在发生异常时回滚事务。

在以上三个步骤中，第三个步骤是最关键的，因为它是通过 Spring AOP 拦截器来实现的。Spring AOP 拦截器是通过代理对象织入到目标方法中的，从而实现对目标方法的拦截和增强。对于 @Transactional 注解，Spring 提供了一个名为 TransactionInterceptor 的拦截器，该拦截器实现了事务管理器的逻辑代码，用于开启、提交或回滚事务。

具体来说，在 TransactionInterceptor 中，会在目标方法开始之前创建一个事务上下文，并使用当前线程作为该事务的唯一标识。当目标方法执行完毕后，如果没有抛出异常，则提交事务，否则回滚事务。除此之外，TransactionInterceptor 还支持基于注解和编程式指定事务的传播机制、隔离级别、只读属性、超时时间等参数，从而使得事务的管理更加灵活和精细。

综上所述，@Transactional 注解的底层实现原理主要依赖于 AOP 和事务管理器。通过 AOP 创建代理对象、织入事务管理器的逻辑代码，并在目标方法执行前后启动和提交/回滚事务，从而实现对 Spring 事务的控制。

#### Spring5.0@Transactional注解TransactionInterceptor 拦截器源码逻辑解读 ####

Spring 5.0 中的 @Transactional 注解主要使用 TransactionInterceptor 拦截器实现了对目标方法的拦截和增强。下面我们来简单解读一下 TransactionInterceptor 的源码逻辑。

public class TransactionInterceptor extends TransactionAspectSupport implements MethodInterceptor, BeanFactoryAware {
        
        // BeanFactory 对象
        private BeanFactory beanFactory;
        
        // 执行目标方法并返回结果
        @Override
        public Object invoke(final MethodInvocation invocation) throws Throwable {
            
            // 获取目标方法
            final Method method = invocation.getMethod();
    
            // 判断是否可以进行事务处理，如果不能则直接执行目标方法
            if (!shouldIntercept(method, null)) {
                return invocation.proceed();
            }
            
            // 获取目标方法所在的类
            final Class<?> targetClass = (invocation.getThis() != null ? AopUtils.getTargetClass(invocation.getThis()) : null);
            
            // 获取事务属性
            final TransactionAttributeSource tas = getTransactionAttributeSource();
            final TransactionAttribute txAttr = (tas != null ? tas.getTransactionAttribute(method, targetClass) : null);
            
            // 如果找不到事务属性，则直接执行目标方法
            if (txAttr == null) {
                return invocation.proceed();
            }
            
            // 获取 PlatformTransactionManager 实例
            final PlatformTransactionManager tm = determineTransactionManager(txAttr);
            final String joinpointIdentification = methodIdentification(method, targetClass, txAttr);
    
            // 创建事务上下文
            TransactionInfo txInfo = createTransactionIfNecessary(tm, txAttr, joinpointIdentification);
    
            Object retVal = null;
            
            try {
                // 执行目标方法
                retVal = invocation.proceed();
            }
            catch (Throwable ex) {
                // 如果出现异常，则将异常信息传递给后续步骤进行处理
                completeTransactionAfterThrowing(txInfo, ex);
                throw ex;
            }
            finally {
                // 完成事务的提交或回滚，并清除当前事务上下文
                cleanupTransactionInfo(txInfo);
            }
    
            // 完成事务的提交或回滚，并清除当前事务上下文
            commitTransactionAfterReturning(txInfo);
            
            return retVal;
        }
        
        // 设置 BeanFactory 对象
        @Override
        public void setBeanFactory(BeanFactory beanFactory) {
            this.beanFactory = beanFactory;
        }
        
        // 获取 PlatformTransactionManager 实例
        protected PlatformTransactionManager determineTransactionManager(TransactionAttribute txAttr) {
            return getTransactionManager();
        }
        
        // 创建事务上下文
        protected TransactionInfo createTransactionIfNecessary(PlatformTransactionManager tm, TransactionAttribute txAttr, String joinpointIdentification) {
            TransactionStatus status = null;
            if (txAttr != null) {
                // 如果事务属性不为空，则开启一个新的事务
                status = tm.getTransaction(txAttr);
            }
            return prepareTransactionInfo(tm, txAttr, joinpointIdentification, status);
        }
        
        // 完成事务的提交或回滚，并清除当前事务上下文
        protected void commitTransactionAfterReturning(TransactionInfo txInfo) {
            if (txInfo != null && txInfo.hasTransaction()) {
                txInfo.getTransactionManager().commit(txInfo.getTransactionStatus());
            }
        }
        
        // 完成事务的提交或回滚，并清除当前事务上下文
        protected void completeTransactionAfterThrowing(TransactionInfo txInfo, Throwable ex) {
            if (txInfo != null && txInfo.hasTransaction()) {
                txInfo.getTransactionManager().rollback(txInfo.getTransactionStatus());
            }
        }
        
        // 清除当前事务上下文
        protected void cleanupTransactionInfo(TransactionInfo txInfo) {
            if (txInfo != null) {
                txInfo.restoreThreadLocalStatus();
            }
        }
    }

TransactionInterceptor 拦截器主要实现了 MethodInterceptor 接口，并重写了 invoke() 方法。在 invoke() 方法中，TransactionInterceptor 会先获取目标方法和目标方法所在类的信息，然后判断是否需要进行事务处理。如果不需要，则直接执行目标方法；否则，就根据获取到的事务属性创建一个新的事务上下文，并开启一个新的事务。

在执行目标方法的过程中，如果出现异常，则 TransactionInterceptor 会通过 completeTransactionAfterThrowing() 方法回滚当前事务，并将异常信息传递给后续步骤进行处理。如果执行正常，则 TransactionInterceptor 会通过 commitTransactionAfterReturning() 方法提交当前事务。

在目标方法执行完毕之后，TransactionInterceptor 还会通过 cleanupTransactionInfo() 方法清除当前事务上下文，从而释放资源。

#### TransactionInterceptor 拦截器的源码逻辑 ####

**创建事务上下文**  
在目标方法执行前，TransactionInterceptor 会调用 TransactionAspectSupport 类的 beforeTransactionExecution() 方法创建一个新的事务上下文，并将其保存到当前线程的 ThreadLocal 中。该事务上下文包含了当前事务所需要的各种参数，例如传播机制、隔离级别、只读属性、超时时间等等。

**开启事务**  
在创建事务上下文之后，TransactionInterceptor 会通过 PlatformTransactionManager 接口调用底层的事务管理器开启一个新的事务，并将该事务与当前事务上下文关联起来。

**执行目标方法**  
在事务开启之后，TransactionInterceptor 会调用 MethodInvocation 的 proceed() 方法执行目标方法的代码逻辑。在目标方法执行过程中，如果出现了异常，则会在目标方法的抛出点处终止执行，并将异常信息传递给后续步骤进行处理。

**提交或回滚事务**  
在目标方法执行完毕之后，TransactionInterceptor 会判断事务是否需要回滚。如果发生异常，并且该异常被定义为需要回滚的异常，则会回滚事务；否则，会提交事务。在提交或回滚事务之后，TransactionInterceptor 会调用 TransactionAspectSupport 类的 afterTransactionExecution() 方法结束当前事务，并将当前事务上下文从当前线程的 ThreadLocal 中清除。

**异常处理**  
在执行目标方法的过程中，如果出现了异常，则 TransactionInterceptor 会根据事务的传播机制和回滚规则进行相应的处理。具体来说，TransactionInterceptor 会根据事务的传播机制判断该异常是应该被抛到上一级调用者，还是在当前方法内部进行回滚；同时，也会根据回滚规则判断该异常是否需要回滚事务。

总结来说，TransactionInterceptor 拦截器的源码逻辑主要包括创建事务上下文、开启事务、执行目标方法、提交或回滚事务以及异常处理等步骤。通过这些步骤的组合，TransactionInterceptor 实现了对目标方法的事务控制和异常处理，从而保证了事务的完成性与一致性。

[c1c854b62b988fdbd21aed0a5922ac50.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/16/3c36fae07e8f4d4c8d8b374e8e56e05e.png
[34184fbd86d98ebc3fc09222935e8712.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/16/8bc9a1686ab64053bbdc397a2b8be57e.png
[Spring]: https://www.processon.com/view/link/5fab6edf1e0853569633cc06