上一篇
如何在Spring项目中正确配置声明式事务管理并避坑？
在现代Java企业级应用开发中,事务管理是保证数据一致性和完整性的核心机制，Spring框架为我们提供了强大而灵活的事务管理功能，声明式事务因其能够将事务管理逻辑从业务代码中分离出来，极大地提升了代码的整洁度和可维护性，成为了开发中的首选方案，本文将深入探讨Spring中声明式事务的配置原理、实现方式以及最佳实践。
声明式事务的底层原理：AOP与代理
声明式事务的魅力在于其“无载入性”，开发者无需在业务方法中编写繁琐的事务开始、提交、回滚代码，而是通过简单的配置或注解即可实现，这一切的背后，是Spring的两大核心利器：面向切面编程（AOP）和动态代理。
当一个类被Spring容器管理,并且其方法被标记为事务性时，Spring会为这个类创建一个代理对象，客户端代码实际调用的是这个代理对象的方法，代理对象在调用真正的目标方法前后，会织入事务管理的“切面”逻辑，这个切面主要负责：
- 获取事务：在方法执行前，根据配置获取一个事务。
- 执行目标方法：调用原始的业务方法。
- 提交或回滚事务：根据目标方法是否抛出异常，决定是提交事务还是回滚事务。
整个过程中,业务代码本身对事务的存在毫无感知，实现了业务逻辑与事务逻辑的完美解耦。
核心配置方式
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 | Propagation枚举 | REQUIRED | 定义事务的传播行为，解决方法嵌套调用时的事务问题。 |
| isolation | Isolation枚举 | DEFAULT | 定义事务的隔离级别，控制并发访问时的数据可见性。 |
| readOnly | boolean | false | 指定事务是否为只读，优化器可据此进行性能优化。 |
| timeout | int (秒) | -1 | 指定事务的超时时间，超过时间则自动回滚。 |
| rollbackFor | Class[] | RuntimeException.class, Error.class | 指定哪些异常需要回滚事务。 |
| noRollbackFor | Class[] | 空数组 | 指定哪些异常不需要回滚事务。 |
传播行为（propagation）是理解事务嵌套的关键，最常用的有：
- REQUIRED（默认）：如果当前存在事务，则加入该事务；否则创建一个新事务。
- REQUIRES_NEW：创建一个新事务，如果当前存在事务，则将当前事务挂起。
- SUPPORTS：如果当前存在事务，则加入该事务；否则以非事务方式执行。
隔离级别（isolation）则遵循数据库的ACID特性，从低到高依次为READ_UNCOMMITTED, READ_COMMITTED, REPEATABLE_READ, SERIALIZABLE，级别越高，数据一致性越好，但并发性能越低。
最佳实践与常见陷阱
- 应用在Service层：事务边界应设在业务逻辑层（Service），而非数据访问层（DAO），因为一个业务操作可能涉及多个DAO的调用，我们需要确保整个业务操作的原子性。
- 注意@Transactional的生效范围：该注解只能应用于public方法，对于protected、private或包可见的方法，不会触发事务，因为Spring无法代理这些方法。
- 避免自调用问题：在同一个类中，一个无事务的方法调用一个有@Transactional注解的方法，事务不会生效，因为这是对象内部的方法调用，没有经过Spring的代理，解决方法是将事务方法提取到另一个Bean中，或者通过AopContext获取当前对象的代理来调用。
- 明确指定回滚异常：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：表示“无论如何都新建一个事务”，如果调用方已经存在一个事务，那么这个事务会被“挂起”，直到新事务执行完成（提交或回滚）后，原挂起的事务才会被恢复，这意味着内外层事务是独立的，内层事务的回滚不会影响外层事务，外层事务的回滚也不会影响已经提交的内层事务，这适用于需要独立事务记录的场景，无论主业务是否成功，都需要记录一条操作日志。
