在 Spring Boot 开发中，@Transactional注解是实现数据库事务管理的重要工具，它能确保数据操作的原子性、一致性、隔离性和持久性（ACID）。本文将深入探讨@Transactional的使用，从基础概念到实战案例，再到常见的使用陷阱和工作实践。

如果对@Transactional 的实现原理感兴趣，可以参考这篇文章：【SpringBoot + MyBatis 事务管理全解析：从 @Transactional 到 JDBC Connection 的旅程】

一、@Transactional 的基本使用

@Transactional注解可以应用在类或方法上，用于声明该类或方法需要进行事务管理。
当@Transactional注解标注在类上时，该类中的所有公共方法都会被纳入事务管理；当标注在方法上时，仅对该方法进行事务管理。

在 Spring Boot 项目中，首先确保在启动类上添加了@EnableTransactionManagement注解，开启事务管理功能。例如：

@SpringBootApplication
@EnableTransactionManagement
public class YourApplication {public static void main(String[] args) {SpringApplication.run(YourApplication.class, args);}
}

然后在需要事务管理的 Service 类或方法上添加@Transactional注解，如下：

@Service
public class UserService {private final UserRepository userRepository;public UserService(UserRepository userRepository) {this.userRepository = userRepository;}@Transactionalpublic void createUser(User user) {userRepository.save(user);// 假设这里还有其他数据库操作// 如果任何操作失败，整个事务将回滚}
}

上述代码中，createUser方法被@Transactional注解修饰，当执行该方法时，如果userRepository.save(user)或后续的数据库操作抛出异常，整个方法的操作都会回滚，保证数据的一致性。

二、@Transactional 的核心属性

@Transactional注解有多个核心属性，了解它们可以更灵活地控制事务行为，以下是主要属性及其默认值：

• propagation：事务传播行为，定义了被调用方法的事务边界。默认值为Propagation.REQUIRED。常见取值及含义如下：
  • Propagation.REQUIRED：如果当前存在事务，则加入该事务；如果当前没有事务，则创建一个新事务。这是最常用的传播行为
  • Propagation.REQUIRES_NEW：创建一个新事务，如果当前存在事务，则将当前事务挂起。新事务独立于当前事务，不受其影响
  • Propagation.SUPPORTS：如果当前存在事务，则加入该事务；如果当前没有事务，则以非事务方式执行
  • Propagation.MANDATORY：如果当前存在事务，则加入该事务；如果当前没有事务，则抛出异常
  • Propagation.NOT_SUPPORTED：以非事务方式执行，如果当前存在事务，则将当前事务挂起
  • Propagation.NEVER：以非事务方式执行，如果当前存在事务，则抛出异常
  • Propagation.NESTED：如果当前存在事务，则创建一个嵌套事务执行；如果当前没有事务，则创建一个新事务。嵌套事务是一个子事务，它的提交和回滚不会影响外部事务，但外部事务回滚会导致嵌套事务回滚

• isolation：事务隔离级别，用于解决事务并发访问时可能出现的问题（如脏读、不可重复读、幻读）。默认值为Isolation.DEFAULT，即使用数据库默认的隔离级别（如 MySQL 默认的REPEATABLE_READ）。常见取值及含义如下：

  • Isolation.DEFAULT：使用数据库默认的隔离级别。
  • Isolation.READ_UNCOMMITTED：最低的隔离级别，允许读取未提交的数据，可能会出现脏读、不可重复读和幻读。
  • Isolation.READ_COMMITTED：只允许读取已提交的数据，可以避免脏读，但可能会出现不可重复读和幻读。
  • Isolation.REPEATABLE_READ：在一个事务内，多次读取同一数据时结果一致，可以避免脏读和不可重复读，但可能会出现幻读。
  • Isolation.SERIALIZABLE：最高的隔离级别，通过强制事务串行执行，避免了所有并发问题，但性能开销最大。

• timeout：事务的超时时间，单位为秒。如果事务执行时间超过该值，将自动回滚。默认值为 -1，表示事务没有超时限制

• rollbackFor：指定需要回滚的异常类型数组。只有当方法抛出的异常属于指定的异常类型时，事务才会回滚。默认情况下，只有运行时异常（RuntimeException及其子类）和错误（Error及其子类）会导致事务回滚

• noRollbackFor：指定不需要回滚的异常类型数组。当方法抛出的异常属于指定的异常类型时，事务不会回滚

Propagation.REQUIRED 与 Propagation.REQUIRES_NEW 的区别及案例

Propagation.REQUIRED和Propagation.REQUIRES_NEW是最容易混淆的两个传播行为，通过以下示例来理解它们的区别。
假设我们有两个 Service 方法：methodA和methodB，methodA调用methodB

使用 Propagation.REQUIRED：

@Service
public class TransactionService {private final AnotherService anotherService;public TransactionService(AnotherService anotherService) {this.anotherService = anotherService;}@Transactional(propagation = Propagation.REQUIRED)public void methodA() {try {// 保存数据A// 假设这里执行成功// 调用methodBanotherService.methodB();// 模拟抛出异常throw new RuntimeException("methodA error");} catch (Exception e) {// 捕获异常}}
}@Service
public class AnotherService {private final SomeRepository someRepository;public AnotherService(SomeRepository someRepository) {this.someRepository = someRepository;}@Transactional(propagation = Propagation.REQUIRED)public void methodB() {// 保存数据B// 假设这里执行成功}
}

在上述代码中，methodA和methodB的传播行为都为Propagation.REQUIRED。当methodA调用methodB时，methodB加入到methodA的事务中。由于methodA后续抛出了异常，整个事务回滚，数据 A 和数据 B 都不会被保存到数据库。

使用 Propagation.REQUIRES_NEW：

@Service
public class TransactionService {private final AnotherService anotherService;public TransactionService(AnotherService anotherService) {this.anotherService = anotherService;}@Transactional(propagation = Propagation.REQUIRED)public void methodA() {try {// 保存数据A// 假设这里执行成功// 调用methodBanotherService.methodB();// 模拟抛出异常throw new RuntimeException("methodA error");} catch (Exception e) {// 捕获异常}}
}@Service
public class AnotherService {private final SomeRepository someRepository;public AnotherService(SomeRepository someRepository) {this.someRepository = someRepository;}@Transactional(propagation = Propagation.REQUIRES_NEW)public void methodB() {// 保存数据B// 假设这里执行成功}
}

这里methodB的传播行为为Propagation.REQUIRES_NEW，当methodA调用methodB时，methodB会创建一个新的独立事务。即使methodA后续抛出异常导致自身事务回滚，methodB的事务已经提交，数据 B 会被成功保存到数据库。

三、使用避坑（失效场景）

在使用@Transactional注解时，存在一些常见的失效场景，需要特别注意：

3.1 自调用问题

自调用问题：在同一个类中，一个方法调用另一个被@Transactional注解的方法时，事务不会生效。这是因为 Spring 的事务管理是基于代理实现的，自调用时方法并没有通过代理对象调用，所以事务不会起作用。

@Service
public class SelfCallService {@Transactionalpublic void outerMethod() {innerMethod();// 模拟抛出异常throw new RuntimeException("outerMethod error");}@Transactionalpublic void innerMethod() {// 数据库操作}
}

上述代码中，outerMethod调用innerMethod，由于是自调用，innerMethod的事务不会生效。当outerMethod抛出异常时，innerMethod中的数据库操作不会回滚。解决方法是将被调用的方法抽取到另一个类中，通过依赖注入的方式调用。

3.2 异常处理不当

异常处理不当：如果在被@Transactional注解的方法中捕获了异常，并且没有重新抛出运行时异常或错误，事务不会回滚。因为 Spring 默认只有在抛出运行时异常或错误时才会触发事务回滚。

@Service
public class ExceptionService {private final SomeRepository someRepository;public ExceptionService(SomeRepository someRepository) {this.someRepository = someRepository;}@Transactionalpublic void handleException() {try {// 数据库操作// 假设这里抛出异常someRepository.save(new SomeEntity());} catch (Exception e) {// 捕获异常但未重新抛出// 事务不会回滚}}
}

解决方法是在捕获异常后，根据业务需求重新抛出运行时异常或合适的异常类型，以触发事务回滚。

3.3 类未被 Spring 管理

类未被 Spring 管理：如果使用@Transactional注解的类没有被 Spring 容器管理（例如没有添加@Component、@Service等注解），事务不会生效。因为 Spring 无法为其创建代理对象来管理事务。

3.4 异步方法内使用失效

异步方法内使用失效：在异步方法（使用@Async注解）内使用@Transactional注解，事务可能不会生效。这是因为异步方法是在另一个线程中执行，脱离了原有的事务上下文。如果需要在异步方法中使用事务，需要特殊处理，例如通过传递事务管理器等方式。

四、工作实践

4.1 事务提交之后执行一些操作

事务提交之后执行一些操作：在某些场景下，需要在事务提交之后执行一些操作，例如发送消息通知、更新缓存等。可以使用TransactionSynchronizationManager来实现

假设我们有一个订单处理系统，在订单创建事务提交后，需要异步发送通知邮件。我们可以通过 TransactionSynchronization 接口监听事务状态，并在事务提交后执行邮件发送任务。

示例代码：

@Service
public class OrderService {@Autowiredprivate OrderRepository orderRepository;@Autowiredprivate EmailService emailService;@Transactionalpublic void createOrder(Order order) {// 保存订单到数据库orderRepository.save(order);// 注册事务同步器，监听事务状态TransactionSynchronizationManager.registerSynchronization(new TransactionSynchronization() {@Overridepublic void afterCommit() {// 事务提交后执行的操作emailService.sendOrderConfirmation(order.getId());}@Overridepublic void afterCompletion(int status) {// 事务完成后执行的操作（无论提交还是回滚）if (status == STATUS_COMMITTED) {// 事务已提交} else if (status == STATUS_ROLLED_BACK) {// 事务已回滚}}});// 其他业务逻辑...}
}@Service
public class EmailService {@Async // 异步方法public void sendOrderConfirmation(Long orderId) {// 模拟发送邮件System.out.println("异步发送订单确认邮件，订单ID: " + orderId);// 实际实现可能调用邮件服务API}
}

4.2 事务 + 分布式锁的场景（先提交事务？先释放锁？）

在高并发业务场景下，如电商系统的订单创建、金融系统的转账操作等，分布式锁与事务的协同使用至关重要。若锁释放与事务提交顺序不当，极易引发数据不一致问题。以下通过订单创建场景，详细说明正确的处理方式。

错误处理方式：先解锁 再 提交事务

@Service
public class OrderServiceWrong {@Transactionalpublic void createOrderWrong(String orderNo, double amount) {String lockValue = lock(orderNo); // 加锁try {if (orderMapper.existsByOrderNo(orderNo)) {return;}orderMapper.insert(new Order(orderNo, amount));} finally {// 错误：先释放锁，事务可能未提交unLock(orderNo, lockValue);}}
}

在上述代码中，若线程 A 获取锁并完成订单创建操作后，先执行了锁释放逻辑。此时，若事务提交因网络延迟等原因未完成，线程 B 可能获取到锁并再次执行订单创建逻辑，导致订单重复创建，破坏数据一致性。

正确处理方式一：事务方法外部释放锁

@Service
public class OrderServiceCorrect2 {public void createOrderCorrect2(String orderNo, double amount) {String lockValue = lock(orderNo); // 加锁try {// 调用带事务的方法boolean success = createOrderInTransaction(orderNo, amount);} catch (Exception e) {// ...} finally {unLock(orderNo, lockValue); // 释放锁}}@Transactionalpublic boolean createOrderInTransaction(String orderNo, double amount) {if (orderMapper.existsByOrderNo(orderNo)) {return false;}orderMapper.insert(new Order(orderNo, amount));return true;}
}

正确处理方式二：使用 TransactionSynchronizationManager

@Service
public class OrderServiceCorrect1 {@Transactionalpublic void createOrderCorrect1(String orderNo, double amount) {String lockValue = lock(orderNo); // 加锁try {if (orderMapper.existsByOrderNo(orderNo)) {return;}orderMapper.insert(new Order(orderNo, amount));// 在事务上下文中注册同步器，确保锁在事务提交后释放TransactionSynchronizationManager.registerSynchronization(new TransactionSynchronization() {@Overridepublic void afterCompletion(int status) {if (status == STATUS_COMMITTED) {unLock(orderNo, lockValue); // 事务提交后释放锁}}});} catch (Exception e) {// 异常处理逻辑unLock(orderNo, lockValue); // 发生异常时直接释放锁throw e;}}
}

结束，✿✿ヽ(°▽°)ノ✿ ！！！