如何在Spring项目中正确配置声明式事务管理并避坑？

在现代Java企业级应用开发中,事务管理是保证数据一致性和完整性的核心机制，Spring框架为我们提供了强大而灵活的事务管理功能，声明式事务因其能够将事务管理逻辑从业务代码中分离出来，极大地提升了代码的整洁度和可维护性，成为了开发中的首选方案，本文将深入探讨Spring中声明式事务的配置原理、实现方式以及最佳实践。

声明式事务的底层原理：AOP与代理

声明式事务的魅力在于其“无侵入性”，开发者无需在业务方法中编写繁琐的事务开始、提交、回滚代码，而是通过简单的配置或注解即可实现，这一切的背后，是Spring的两大核心利器：面向切面编程（AOP）和动态代理。

当一个类被Spring容器管理,并且其方法被标记为事务性时，Spring会为这个类创建一个代理对象，客户端代码实际调用的是这个代理对象的方法，代理对象在调用真正的目标方法前后，会织入事务管理的“切面”逻辑，这个切面主要负责：

1. 获取事务：在方法执行前，根据配置获取一个事务。
2. 执行目标方法：调用原始的业务方法。
3. 提交或回滚事务：根据目标方法是否抛出异常，决定是提交事务还是回滚事务。

整个过程中,业务代码本身对事务的存在毫无感知，实现了业务逻辑与事务逻辑的完美解耦。

核心配置方式

Spring提供了多种配置声明式事务的方式,主要分为基于XML的传统配置和基于注解的现代化配置。

基于XML的配置

在早期的Spring项目中,XML配置是主流，其核心是在Spring的配置文件中启用事务注解驱动，并配置一个事务管理器。

<!-- 1. 配置数据源 -->
<bean id="dataSource" class="org.apache.commons.dbcp2.BasicDataSource">
    <property name="driverClassName" value="com.mysql.cj.jdbc.Driver"/>
    <property name="url" value="jdbc:mysql://localhost:3306/mydb"/>
    <property name="username" value="root"/>
    <property name="password" value="password"/>
</bean>
<!-- 2. 配置事务管理器 -->
<bean id="transactionManager" class="org.springframework.jdbc.datasource.DataSourceTransactionManager">
    <property name="dataSource" ref="dataSource"/>
</bean>
<!-- 3. 启用注解驱动的事务管理 -->
<tx:annotation-driven transaction-manager="transactionManager"/>
<!-- 4. 配置Service Bean -->
<bean id="userService" class="com.example.service.UserServiceImpl"/>

配置完成后,只需在Service层的方法或类上添加@Transactional注解即可。

基于Java Config的配置

随着Spring Boot的普及，基于Java类的配置方式成为新标准，它更加类型安全且易于管理。

@Configuration
@EnableTransactionManagement // 启用注解驱动的事务管理
public class TransactionConfig {
    @Bean
    public DataSource dataSource() {
        // 配置并返回数据源
        return new EmbeddedDatabaseBuilder()
                .setType(EmbeddedDatabaseType.H2)
                .addScript("schema.sql")
                .build();
    }
    @Bean
    public PlatformTransactionManager transactionManager(DataSource dataSource) {
        // 配置事务管理器，并注入数据源
        return new DataSourceTransactionManager(dataSource);
    }
}

@EnableTransactionManagement注解的作用等同于XML中的<tx:annotation-driven>，同样，结合@Transactional注解即可实现事务控制。

精通@Transactional注解

@Transactional注解是声明式事务的核心，它提供了丰富的属性来精细控制事务行为。

传播行为（propagation）是理解事务嵌套的关键，最常用的有：

• REQUIRED（默认）：如果当前存在事务，则加入该事务；否则创建一个新事务。
• REQUIRES_NEW：创建一个新事务，如果当前存在事务，则将当前事务挂起。
• SUPPORTS：如果当前存在事务，则加入该事务；否则以非事务方式执行。

隔离级别（isolation）则遵循数据库的ACID特性，从低到高依次为READ_UNCOMMITTED, READ_COMMITTED, REPEATABLE_READ, SERIALIZABLE，级别越高，数据一致性越好，但并发性能越低。

最佳实践与常见陷阱

1. 应用在Service层：事务边界应设在业务逻辑层（Service），而非数据访问层（DAO），因为一个业务操作可能涉及多个DAO的调用，我们需要确保整个业务操作的原子性。
2. 注意@Transactional的生效范围：该注解只能应用于public方法，对于protected、private或包可见的方法，不会触发事务，因为Spring无法代理这些方法。
3. 避免自调用问题：在同一个类中，一个无事务的方法调用一个有@Transactional注解的方法，事务不会生效，因为这是对象内部的方法调用，没有经过Spring的代理，解决方法是将事务方法提取到另一个Bean中，或者通过AopContext获取当前对象的代理来调用。
4. 明确指定回滚异常：Spring默认只对RuntimeException和Error进行回滚，对于业务中抛出的受检异常，需要通过rollbackFor属性明确指定，否则事务不会回滚。

相关问答FAQs

问题1：为什么 @Transactional 注解在 private 方法上不起作用？

解答： 这是因为Spring的声明式事务是基于AOP动态代理实现的，Spring在运行时会为目标类创建一个代理对象，外部调用的是代理对象的方法，代理对象在调用前后会织入事务切面逻辑，代理对象只能拦截从外部调用的public方法，当一个private方法在类的内部被调用时（this.somePrivateMethod()），这个调用绕过了代理对象，直接作用于原始目标实例，因此事务切面无法被触发，事务也就不会生效。

问题2：propagation = Propagation.REQUIRED 和 propagation = Propagation.REQUIRES_NEW 有什么本质区别？

解答： 两者的核心区别在于如何处理已存在的事务。

• REQUIRED：表示“如果当前存在事务，就加入其中；否则，新建一个事务”，这意味着内外层方法共享同一个事务，如果内层方法抛出异常导致回滚，那么整个外部事务也会回滚，反之，外部事务的回滚也会导致内层操作回滚，它们在逻辑上是一个整体。

• REQUIRES_NEW：表示“无论如何都新建一个事务”，如果调用方已经存在一个事务，那么这个事务会被“挂起”，直到新事务执行完成（提交或回滚）后，原挂起的事务才会被恢复，这意味着内外层事务是独立的，内层事务的回滚不会影响外层事务，外层事务的回滚也不会影响已经提交的内层事务，这适用于需要独立事务记录的场景，无论主业务是否成功，都需要记录一条操作日志。