事务管理

本文从基础理论→数据库层实现→Spring框架封装→底层原理→实践坑点全链路，系统性梳理事务管理的核心知识体系，覆盖ACID特性、隔离级别、传播行为、@Transactional底层原理与失效场景五大核心模块。

一、事务核心基石：ACID四大特性

事务是数据库操作的最小不可分割执行单元，核心目标是保证一组数据库操作「要么全成功执行，要么全失败回滚」，最终保障数据一致性。ACID是事务的四大核心特性，其中一致性是最终目标，原子性、隔离性、持久性是实现一致性的核心保障。

二、事务并发问题与隔离级别

隔离级别是数据库层对事务隔离性的具体落地实现，定义了并发事务之间的可见性规则，用于解决并发事务引发的读异常问题。

2.1 并发事务引发的3大核心读异常

2.2 SQL标准4大隔离级别

从低到高分为4个等级，隔离级别越高，并发性能越差，数据安全性越高。

2.3 核心补充：MVCC与隔离级别的关联

MVCC（多版本并发控制）是InnoDB实现隔离级别的核心底层机制，通过undo log保存数据的历史版本，实现「不加锁的读-写并发」：

• RC级别：每次执行SELECT语句，都会生成一个全新的Read View（读视图），因此每次都能读到其他事务最新提交的数据，无法避免不可重复读。
• RR级别：事务启动后第一次执行SELECT时生成Read View，整个事务生命周期内复用该视图，因此保证了同一事务内多次读取结果一致，实现可重复读。

三、Spring事务传播行为

传播行为是Spring框架特有的、应用层的事务控制规则，与数据库隔离级别完全解耦。它定义了：当一个被@Transactional注解修饰的方法，被另一个事务方法调用时，当前事务如何在调用者与被调用者之间传播，核心是控制事务的边界、创建、复用与挂起行为。

Spring共定义了7种传播行为，分为3大类，核心默认值为REQUIRED。

3.1 第一类：支持当前事务（优先加入已有事务）

3.2 第二类：不支持当前事务（强制独立/非事务执行）

3.3 第三类：嵌套事务

3.4 核心高频传播行为对比

四、@Transactional底层实现原理

@Transactional是Spring声明式事务的核心注解，本质是基于AOP面向切面编程实现，对目标方法进行动态代理，在方法执行前后织入事务的开启、提交、回滚逻辑，底层完全依赖数据库的事务能力。

4.1 核心前提：Spring动态代理机制

Spring为被@Transactional修饰的Bean生成动态代理对象，只有通过代理对象调用目标方法，才能触发事务拦截逻辑。Spring提供两种代理实现：

1. JDK动态代理：基于接口实现，要求目标类必须实现接口，生成接口的代理实现类。
2. CGLIB动态代理：基于继承实现，目标类无需实现接口，生成目标类的子类作为代理类，Spring Boot 2.x开始默认使用该方式。

关键限制：只有public非final、非static的方法，才能被动态代理拦截，这是后续大量失效场景的核心根源。

4.2 完整执行流程（事务全生命周期）

1. 代理对象生成：Spring容器启动时，扫描所有被@Transactional修饰的Bean，为其生成动态代理对象，注入事务拦截器。
2. 方法调用拦截：外部调用目标方法时，不会直接执行原始业务方法，而是先调用代理对象，被TransactionInterceptor（事务拦截器） 拦截。
3. 事务属性解析：事务拦截器通过TransactionAttributeSource解析@Transactional注解的配置（隔离级别、传播行为、回滚规则、超时时间等）。
4. 事务管理器创建事务：调用核心接口PlatformTransactionManager，根据传播行为判断是否新建事务、复用已有事务、挂起现有事务，并获取数据库连接。
5. 连接线程绑定：通过DataSourceUtils将获取到的数据库Connection绑定到当前线程的ThreadLocal中，保证同一个事务内的所有操作，使用同一个数据库连接，这是事务原子性的核心基础。
6. 执行业务方法：事务开启完成后，调用目标Bean的原始业务方法，执行数据库操作。
7. 异常处理与回滚判断：
   • 若业务方法抛出异常，根据rollbackFor规则判断是否回滚：默认仅对RuntimeException和Error触发回滚，受检异常（Exception）默认不回滚。
   • 若符合回滚规则，调用事务管理器的rollback()方法执行回滚。
8. 事务提交：若业务方法正常执行完成，未抛出符合回滚规则的异常，调用事务管理器的commit()方法提交事务。
9. 资源清理：事务提交/回滚完成后，解除ThreadLocal中绑定的数据库连接，将连接归还连接池，恢复被挂起的事务（如有）。

4.3 核心底层组件

五、@Transactional失效场景全解

失效场景的核心本质是：违反了Spring动态代理的拦截规则、注解配置不符合预期、异常处理未触发回滚规则、底层数据库不支持事务四大类，以下为全场景覆盖，含失效原因与解决方案。

5.1 第一类：代理机制相关失效（最常见，占比最高）

1. 方法非public修饰

   • 失效原因：Spring AOP仅能拦截public方法，private、protected、default修饰的方法无法被动态代理拦截，注解完全无效。
   • 解决方案：将事务方法改为public修饰。

2. 类内部方法调用（this调用）

   • 失效原因：@Transactional基于动态代理生效，只有外部调用代理对象的方法才会被拦截。类内部通过this调用本类方法，调用的是原始对象而非代理对象，无法触发事务拦截。
   • 典型示例：A类的无事务方法methodA()，通过this.methodB()调用本类加了@Transactional的methodB()，methodB的事务完全失效。
   • 解决方案：
     1. 最优方案：将被调用的事务方法拆分到独立的Bean中，通过Spring注入后调用。
     2. 备选方案：在本类中注入自身代理对象，通过代理对象调用内部方法。
     3. 终极方案：使用AspectJ静态代理替代Spring动态代理，彻底解决内部调用问题。

3. 方法被final/static修饰

   • 失效原因：CGLIB动态代理通过生成目标类的子类实现，final方法无法被子类重写；static方法属于类而非实例对象，均无法被代理拦截，注解失效。
   • 解决方案：移除方法的final、static修饰符，改为实例的public非final方法。

4. Bean未被Spring容器管理

   • 失效原因：@Transactional的代理对象由Spring IOC容器生成，若目标类未添加@Service/@Component等注解，未被容器管理，无法生成代理对象，注解失效。
   • 解决方案：将目标类纳入Spring IOC容器管理。

5.2 第二类：注解属性配置错误导致的失效

1. rollbackFor配置错误（高频生产坑）

   • 失效原因：@Transactional默认仅对RuntimeException和Error触发回滚，对于受检异常（如IOException、SQLException、自定义受检异常），默认不会回滚。若未配置rollbackFor，抛出受检异常时事务不会回滚。
   • 解决方案：显式配置@Transactional(rollbackFor = Exception.class)，覆盖所有异常类型，避免漏回滚。

2. 传播行为配置错误

   • 失效原因：使用了不支持事务的传播行为，如SUPPORTS（无事务时以非事务执行）、NOT_SUPPORTED（强制非事务执行），导致事务未被创建。
   • 解决方案：根据业务场景正确选择传播行为，常规场景使用默认的REQUIRED即可。

3. 多数据源场景未指定事务管理器

   • 失效原因：多数据源项目中，若未给每个数据源配置独立的事务管理器，或未通过transactionManager属性指定对应管理器，@Transactional无法找到正确的事务管理器，导致失效。
   • 解决方案：多数据源场景下，显式指定@Transactional(transactionManager = "xxxTransactionManager")。

4. 超时时间配置无效

   • 失效原因：timeout属性仅对新建的事务生效，若传播行为为加入已有事务，timeout配置会被忽略；部分数据库不支持事务超时设置。
   • 解决方案：在新建事务的方法上配置timeout，确保传播行为为REQUIRED（无事务时新建）或REQUIRES_NEW。

5.3 第三类：异常处理错误导致的失效

1. 异常被try-catch捕获，未向外抛出

   • 失效原因：Spring事务只有捕获到方法抛出的、符合回滚规则的异常时，才会触发回滚。若方法内通过try-catch将异常“吃掉”，未向外抛出，事务拦截器无法感知异常，不会执行回滚。
   • 典型示例：方法内捕获Exception，仅打印日志，未重新抛出，事务不回滚。
   • 解决方案：
     1. 方案1：捕获异常后，重新抛出符合rollbackFor规则的异常。
     2. 方案2：catch块中手动触发回滚：TransactionAspectSupport.currentTransactionStatus().setRollbackOnly();

2. 抛出的异常与rollbackFor配置不匹配

   • 失效原因：配置了rollbackFor = 自定义异常类，但方法抛出的异常不在配置范围内，导致事务不回滚。
   • 解决方案：rollbackFor配置覆盖所有需要回滚的异常，推荐直接配置Exception.class。

5.4 第四类：特殊场景与底层机制导致的失效

1. 多线程调用导致事务失效

   • 失效原因：Spring事务的数据库连接绑定在ThreadLocal中，多线程场景下，子线程与主线程不属于同一个ThreadLocal，无法获取主线程的数据库连接，子线程的操作不在主线程的事务中，事务失效。
   • 解决方案：多线程场景下使用分布式事务（如Seata），或确保所有事务操作在同一个线程内执行。

2. 数据库不支持事务

   • 失效原因：如MySQL的MyISAM存储引擎不支持事务，只有InnoDB支持。若表使用MyISAM引擎，@Transactional完全无效。
   • 解决方案：将表的存储引擎改为InnoDB。

3. 事务方法内执行DDL语句

   • 失效原因：create、alter、drop等DDL语句，执行后会被数据库隐式提交当前事务，导致后续操作报错时无法回滚。
   • 解决方案：严禁在事务方法内执行DDL语句，DDL操作单独处理。

4. 嵌套事务NESTED使用错误

   • 失效原因：NESTED传播行为依赖数据库的Savepoint机制，且需要事务管理器开启nestedTransactionAllowed = true，否则会退化为REQUIRED，导致预期的嵌套回滚失效。
   • 解决方案：使用NESTED时，确保事务管理器开启嵌套事务支持，且数据库支持Savepoint。

六、事务管理最佳实践

1. 优先使用声明式事务@Transactional，避免编程式事务，降低代码耦合度。
2. 注解必须加在public方法上，严禁类内部this调用事务方法，必须内部调用时使用代理对象。
3. 强制显式配置rollbackFor = Exception.class，避免受检异常不回滚的生产事故。
4. 控制事务粒度尽可能小，避免大事务：严禁在事务内执行RPC调用、HTTP请求、文件IO等耗时操作，减少锁持有时间，提升并发性能。
5. 常规场景使用默认的REQUIRED传播行为，需要独立事务用REQUIRES_NEW，精细化回滚用NESTED，避免滥用传播行为。
6. 多数据源场景下，必须显式指定transactionManager，避免事务失效。
7. 严禁在事务内执行DDL语句，防止隐式提交导致的回滚失效。
8. 线上环境避免使用串行化、读未提交隔离级别，MySQL默认RR级别、Oracle默认RC级别为最优解。