SpringBoot 中 @Transactional 的使用

在 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;
    }

    @Transactional
    public 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
            // 假设这里执行成功
            // 调用methodB
            anotherService.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
            // 假设这里执行成功
            // 调用methodB
            anotherService.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 {

    @Transactional
    public void outerMethod() {
        innerMethod();
        // 模拟抛出异常
        throw new RuntimeException("outerMethod error");
    }

    @Transactional
    public 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;
    }

    @Transactional
    public 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 {

    @Autowired
    private OrderRepository orderRepository;
    
    @Autowired
    private EmailService emailService;

   
    @Transactional
    public void createOrder(Order order) {
        // 保存订单到数据库
        orderRepository.save(order);
        
        // 注册事务同步器，监听事务状态
        TransactionSynchronizationManager.registerSynchronization(new TransactionSynchronization() {
            
            @Override
            public void afterCommit() {
                // 事务提交后执行的操作
                emailService.sendOrderConfirmation(order.getId());
            }
            
            @Override
            public 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 {

    @Transactional
    public 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); // 释放锁
		}
    }

    @Transactional
    public 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 {

    @Transactional
    public 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() {
                @Override
                public void afterCompletion(int status) {
                    if (status == STATUS_COMMITTED) {
                        unLock(orderNo, lockValue); // 事务提交后释放锁
                    }
                }
            });
        } catch (Exception e) {
            // 异常处理逻辑
            unLock(orderNo, lockValue); // 发生异常时直接释放锁
            throw e;
        }
    }
}

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