Spring声明式事务配置不生效，到底是哪里错了？

在现代化的企业级应用开发中，事务管理是确保数据一致性和完整性的核心机制，Spring框架通过其强大的AOP（面向切面编程）特性，提供了一种极为优雅的事务管理方式——声明式事务，它允许开发者将事务逻辑从业务代码中解耦，通过配置或注解的方式非侵入式地管理事务,极大地提升了代码的简洁性和可维护性。

核心原理与组件

声明式事务的底层实现依赖于Spring AOP，当容器启动时，Spring会为配置了事务的Bean（或其方法）创建一个代理对象，当应用程序通过代理对象调用方法时，Spring会在方法调用前后“织入”事务管理的逻辑，例如在方法执行前开启一个事务，在方法成功执行后提交事务，或在方法抛出特定异常时回滚事务，整个过程对开发者是透明的,仿佛业务代码本身就具备了事务能力。

实现声明式事务主要依赖三大核心组件：

1. PlatformTransactionManager：事务管理器接口，是事务管理的核心，它定义了事务的基本操作，如获取事务、提交和回滚，Spring为不同的持久化技术提供了多种实现，如DataSourceTransactionManager（用于JDBC）、HibernateTransactionManager（用于Hibernate）、JpaTransactionManager（用于JPA）等。
2. @Transactional：这是开发者最常接触的注解，用于声明在哪个类或方法上应用事务,它提供了丰富的属性来精细化控制事务行为。
3. @EnableTransactionManagement：在配置类上添加此注解,用于显式启用Spring的注解驱动事务管理功能。

主流配置方式：基于注解

随着Spring Boot的普及，基于注解的配置已成为绝对主流，这种方式简洁明了，与代码的耦合度最低,下面是一个典型的配置流程。

在配置类中定义一个PlatformTransactionManager的Bean，以Spring Boot整合JPA为例，Spring Boot会自动配置DataSource和JpaTransactionManager，通常我们无需手动定义，但在非Spring Boot项目或需要自定义时,可以这样配置：

@Configuration
@EnableTransactionManagement // 启用声明式事务
public class TransactionConfig {
    @Bean
    public PlatformTransactionManager transactionManager(DataSource dataSource) {
        return new DataSourceTransactionManager(dataSource);
    }
}

在需要事务管理的Service层方法或类上添加@Transactional注解。

@Service
public class OrderServiceImpl implements OrderService {
    @Autowired
    private OrderRepository orderRepository;
    @Autowired
    private AccountRepository accountRepository;
    @Override
    @Transactional // 应用在方法上
    public void placeOrder(Order order) {
        // 1. 扣减用户账户余额
        accountRepository.deductBalance(order.getUserId(), order.getAmount());
        // 2. 创建订单记录
        orderRepository.save(order);
        // 如果在此过程中发生任何未被捕获的RuntimeException，事务将自动回滚
    }
}

将@Transactional注解添加在类级别，意味着该类中所有的public方法都将被事务管理。

@Transactional注解核心属性详解

@Transactional注解的强大之处在于其可配置的属性,允许开发者精确控制事务的边界和行为。

传播行为和隔离级别是两个最为关键且容易混淆的概念。

• 传播行为（propagation）：

  • REQUIRED（默认）：如果当前存在事务，则加入该事务；如果不存在，则创建一个新事务,这是最常用的选择。
  • REQUIRES_NEW：总是创建一个新事务，如果当前存在事务,则将当前事务挂起。
  • SUPPORTS：如果当前存在事务，则加入该事务；如果不存在,则以非事务方式执行。
  • NOT_SUPPORTED：以非事务方式执行，如果当前存在事务,则将其挂起。
  • MANDATORY：必须在一个已有事务中执行,否则抛出异常。
  • NEVER：以非事务方式执行，如果当前存在事务,则抛出异常。
  • NESTED：如果当前存在事务，则在嵌套事务中执行，嵌套事务是独立于当前事务的子事务，它可以独立提交或回滚，但其回滚不会影响外部事务，如果当前没有事务，则行为与REQUIRED类似。

• 隔离级别（isolation）：

  

  • DEFAULT：使用底层数据库的默认隔离级别。
  • READ_UNCOMMITTED：读未提交，一个事务可以读取到另一个事务未提交的数据，存在脏读、不可重复读、幻读问题。
  • READ_COMMITTED：读已提交，一个事务只能读取到另一个事务已提交的数据，避免了脏读，但存在不可重复读、幻读问题。
  • REPEATABLE_READ：可重复读，确保在同一个事务中多次读取同一数据的结果一致，避免了脏读和不可重复读，但可能存在幻读,MySQL的InnoDB引擎默认级别。
  • SERIALIZABLE：串行化，最高的隔离级别，所有事务按顺序执行，完全避免了并发问题,但性能开销巨大。

常见陷阱与最佳实践

1. 自调用问题：在同一个类中，一个没有@Transactional注解的方法调用另一个有@Transactional注解的方法，事务不会生效，这是因为Spring AOP是基于代理实现的，内部方法调用绕过了代理对象，因此事务切面无法被应用，解决方法包括：将事务方法移到另一个Service类中、通过注入自身代理来调用，或使用AopContext.currentProxy()。
2. 访问权限问题：@Transactional注解只能应用于public方法，对于protected、private或包可见的方法，虽然不会报错，但事务不会生效,因为代理对象无法访问这些方法。
3. 异常处理：默认情况下，Spring只对RuntimeException和Error类型的异常进行回滚，对于受检异常（Checked Exception），则不会回滚，如果希望特定受检异常也能触发回滚，必须使用@Transactional(rollbackFor = Exception.class)进行明确配置。
4. readOnly的正确使用：将查询方法标记为@Transactional(readOnly = true)是一个好习惯，它能为数据库提供优化提示，但要注意，如果在该方法中执行了写操作,某些数据库驱动可能会抛出异常。

相关问答FAQs

Q1：为什么在同一个类中调用一个@Transactional方法有时会不起作用？

A1： 这个问题是由于Spring AOP的代理机制造成的，当一个类被Spring事务管理时，Spring会创建一个该类的代理对象，外部调用通过代理对象时，AOP切面（事务逻辑）得以执行，但如果是在类内部的一个方法直接调用同类的另一个带@Transactional注解的方法（即this.methodB()），这个调用是直接的目标对象调用，没有经过代理，因此事务切面无法被织入，导致事务失效，解决方法有：将事务方法放到另一个Bean中；通过AopContext.currentProxy()获取当前代理对象来调用；或者在类中注入自身（通过构造器或@Autowired）来调用。

Q2：默认情况下，Spring事务会为所有异常回滚吗？如果不是，我该如何配置它？

A2： 不是的，Spring事务默认的回滚策略是：当方法抛出RuntimeException（运行时异常）或Error类型的异常时，触发事务回滚，对于受检异常，也就是代码中必须显式处理或通过throws声明的异常（如IOException, SQLException），Spring默认不会回滚事务，如果你希望任何异常（包括受检异常）都触发回滚，可以在@Transactional注解中使用rollbackFor属性进行配置，@Transactional(rollbackFor = Exception.class)，这样，无论方法抛出何种异常，事务都会被回滚，反之，如果你想指定某个运行时异常不回滚，可以使用noRollbackFor属性。