Spring 框架为开发者提供了一套强大且灵活的事务管理机制。无论是复杂的分布式系统还是简单的单体应用，Spring 的事务抽象层都能让我们以统一、简洁的方式控制事务行为。本文将从为什么使用 Spring 事务开始，深入探讨其核心配置、工作原理、关键属性以及常见的坑点与最佳实践。

第一部分：为何选择 Spring 的事务模型？

在传统的 JDBC 操作中，我们需要手动处理 Connection 对象的获取、提交（commit）和回滚（rollback），代码冗余且极易出错。虽然 JTA (Java Transaction API) 提供了跨资源的事务能力，但其 API 相对复杂。

Spring 优雅地解决了这些问题。通过提供一致的编程模型，它让开发者无论是在简单的 JDBC 环境还是复杂的 JTA 环境中，都能以相同的方式管理事务。这极大地降低了学习成本和代码耦合度。

Spring 框架提供了两种核心的事务管理方式：

  • 编程式事务管理：在代码中通过 TransactionTemplate 或直接使用 PlatformTransactionManager API 手动控制事务。这种方式更为灵活，但侵入性强。
  • 声明式事务管理：基于 AOP (面向切面编程)，通过 @Transactional 注解来管理事务。这是目前最流行也是 Spring 官方推荐的方式，因为它将业务代码与事务管理代码彻底解耦，保持了 POJO 的纯净。

第二部分：核心配置：TransactionManager 的幕后英雄

要让声明式事务生效，必须在 Spring 容器中正确配置一个 PlatformTransactionManager Bean。这个管理器是 Spring 事务基础设施的核心，负责执行事务的创建、提交和回滚。

对于基于 JDBC 的应用，我们通常使用 DataSourceTransactionManager。以下是一个典型的基于 Java 的配置：

@Configuration
@EnableTransactionManagement // 开启声明式事务管理能力
@PropertySource("classpath:jdbc.properties") 
public class DataSourceConfig {

    @Value("${jdbc.driverClassName}")
    private String driverClassName;

    @Value("${jdbc.url}")
    private String url;

    @Value("${jdbc.username}")
    private String username;

    @Value("${jdbc.password}")
    private String password;

    /**
     * 配置数据源
     */
    @Bean(destroyMethod = "close") 
    public DataSource dataSource() {
        BasicDataSource dataSource = new BasicDataSource();
        dataSource.setDriverClassName(driverClassName);
        dataSource.setUrl(url);
        dataSource.setUsername(username);
        dataSource.setPassword(password);
        return dataSource;
    }

    /**
     * 配置事务管理器，并注入数据源
     */
    @Bean
    public PlatformTransactionManager txManager(DataSource dataSource) {
        return new DataSourceTransactionManager(dataSource);
    }
}

@EnableTransactionManagement 注解是激活声明式事务处理能力的关键。配置完成后，我们就可以在代码中使用 @Transactional 注解了。

第三部分：@Transactional 的魔力：AOP 代理机制

你可能会好奇，一个简单的 @Transactional 注解是如何实现事务自动开启和关闭的？答案是 AOP (面向切面编程)。

当 Spring 容器检测到一个 Bean 的方法被标注了 @Transactional 时，它不会直接返回该 Bean 的实例，而是为该 Bean 创建一个 代理 (Proxy)。此后所有对该 Bean 方法的调用都会先经过这个代理对象。

代理对象内部包含了一个 TransactionInterceptor（事务拦截器），它会在目标方法执行前开启事务，在方法执行成功后提交事务，如果方法抛出异常则回滚事务。

第四部分：深入探讨 @Transactional 的核心属性

@Transactional 注解提供了丰富的属性，让我们能精细化地控制事务行为。

1. 回滚规则 (rollbackFor & noRollbackFor)

一个常见的误区是认为 @Transactional 会在任何异常发生时回滚事务。

Spring 默认的回滚规则是：

  • 当方法抛出 RuntimeException 或其子类时，事务回滚。
  • 当方法抛出 Error 时，事务回滚。
  • 当方法抛出 受检异常 (Checked Exception，即非 RuntimeException) 时，事务不会回滚。

这种默认行为在很多场景下是不安全的（例如 SQLException 和 IOException 都是受检异常）。因此，在企业级项目中，我们通常会显式指定回滚规则，让所有异常都触发回滚。

// 推荐做法：让所有 Exception 及其子类都触发回滚
@Transactional(rollbackFor = Exception.class)
public void someBusinessMethod() throws IOException {
    // ...
}

2. 事务传播行为 (propagation)

事务传播行为定义了当一个已有事务的方法调用另一个有事务的方法时，事务应该如何表现。

最常用的传播行为包括：

  • REQUIRED (默认)：如果当前存在事务，则加入该事务；如果当前没有事务，则创建一个新的事务。这是最常见的选择。
  • REQUIRES_NEW：总是创建一个新的事务。如果当前存在事务，则将当前事务挂起。
  • NESTED：如果当前存在事务，则创建一个嵌套事务（保存点）；如果当前没有事务，其行为等同于 REQUIRED。

3. 隔离级别 (isolation)

事务隔离级别定义了一个事务可能受其他并发事务影响的程度。不合适的隔离级别会导致脏读、不可重复读和幻读。

@Transactional 支持以下隔离级别：

  • READ_COMMITTED：仅允许读取已提交的数据，可防止脏读。这是大多数数据库（如 Oracle, PostgreSQL）的默认隔离级别。
  • REPEATABLE_READ：确保在同一事务内多次读取同一数据的结果是一致的，可防止脏读和不可重复读。但仍可能出现幻读。这是 MySQL 的默认隔离级别。

第五部分：常见坑点与最佳实践

1. 被 @Transactional 标注的方法必须是 public

Spring 的 AOP 代理默认只拦截 public 方法。如果将 @Transactional 用于 protected、private 或包内可见的方法，事务将不会生效。

2. “自我调用”失效问题

这是最常见且隐蔽的坑。当类中的方法 A 调用同类中的方法 B 时 (this.B())，即使方法 B 标注了 @Transactional，事务也不会生效。

原因：因为方法 A 是通过 this 直接调用的，绕过了 Spring 创建的 AOP 代理对象。既然没走代理，事务拦截器自然无法工作。

3. 建议将注解标注在具体类上

Spring 团队建议在具体的实现类及其方法上使用 @Transactional 注解，而不是标注在接口上。虽然标注在接口上也能工作，但类级别的注解更清晰、更直接。

总结

Spring 的声明式事务管理是一个强大且优雅的工具。通过深入理解其背后的 AOP 原理，熟练运用回滚规则、传播行为和隔离级别等核心属性，并警惕自我调用失效等常见陷阱，我们就能在项目中构建出稳健、易于维护的数据访问层。