Spring配置事务有哪些方式，事务管理详细教程？

Spring配置事务的推荐方案是：优先使用基于注解的声明式事务（@Transactional），并结合XML或Java Config进行事务管理器与切面的显式配置。 这种组合既能保证事务边界清晰、代码侵入性低，又能应对复杂场景下的细粒度控制，是生产环境中最稳健、可维护性最高的实践。

Spring事务配置的底层逻辑

Spring事务的本质是对数据库事务的抽象与增强，它通过PlatformTransactionManager接口统一管理不同数据源（JDBC、JPA、Hibernate等）的事务，配置事务时，核心是三件事：

• 事务管理器：确定使用哪种底层实现，例如DataSourceTransactionManager。
• 事务通知：定义事务的传播行为、隔离级别、回滚规则等。
• 切面织入：将事务增强应用到目标方法上。

无论采用XML还是注解,最终都是围绕这三要素展开，理解这一点后，配置事务就不会被各种写法迷惑。

基于注解的声明式事务（首选方案）

基础配置步骤

配置事务管理器

在Java Config中，注入DataSource并创建DataSourceTransactionManager：

@Bean
public PlatformTransactionManager transactionManager(DataSource dataSource) {
    return new DataSourceTransactionManager(dataSource);
}

若使用XML,则对应为：

<bean id="transactionManager" class="org.springframework.jdbc.datasource.DataSourceTransactionManager">
    <property name="dataSource" ref="dataSource"/>
</bean>

开启注解驱动

在配置类上添加@EnableTransactionManagement，或在XML中添加<tx:annotation-driven transaction-manager="transactionManager"/>。

在Service类或方法上使用@Transactional

@Service
public class OrderService {
    @Transactional
    public void createOrder(Order order) {
        // 业务逻辑
    }
}

关键属性详解

• propagation（传播行为）

  

  ：默认REQUIRED，即当前有事务则加入，无则新建，对于独立子任务可使用REQUIRES_NEW。

• isolation（隔离级别）：默认DEFAULT（由数据库决定），高并发场景建议显式设置READ_COMMITTED，避免不可重复读与幻读。
• rollbackFor：默认只回滚RuntimeException和Error，若需要检查型异常也回滚，必须显式声明rollbackFor = Exception.class。
• readOnly：对只读操作设为true，可优化数据库连接资源，但不建议在增删改方法上使用。

常见误用与修正

同类内部方法调用导致事务失效

public void outer() {
    inner(); // 直接调用，不走代理，事务失效
}
@Transactional
public void inner() { ... }

解决方案：通过代理对象调用，或拆分到不同Bean中。

@Transactional加在非public方法上

Spring默认不代理非public方法,事务不会生效，请确保目标方法为public。

抛出异常后未触发回滚

若在方法内自行捕获异常,事务不会感知到，必须向外抛出异常。

基于XML的事务配置（适用于老项目或复杂AOP）

虽然注解配置是主流,但XML在需要批量定义多个事务策略（如不同包路径使用不同的事务管理器）时仍有优势。

经典配置片段

<tx:advice id="txAdvice" transaction-manager="transactionManager">
    <tx:attributes>
        <tx:method name="save" propagation="REQUIRED" rollback-for="Exception.class"/>
        <tx:method name="query" read-only="true"/>
        <tx:method name="" propagation="REQUIRED"/>
    </tx:attributes>
</tx:advice>
<aop:config>
    <aop:pointcut id="servicePointcut" expression="execution( com.example.service..(..))"/>
    <aop:advisor advice-ref="txAdvice" pointcut-ref="servicePointcut"/>
</aop:config>

这种方式通过通配符统一管理事务规则，尤其适合旧系统快速完成事务覆盖。

XML配置的优劣权衡

• 优点：规则集中，灵活支持多事务管理器；修改无需重新编译。
• 缺点：XML冗长，可读性差；与业务代码分离，调试相对困难。

现代新项目建议以注解为主,XML仅在必要的AOP场景下作为补充。

编程式事务：保持底线的可选方案

当声明式事务无法满足需求（例如事务边界需要动态控制），可使用TransactionTemplate：

@Service
public class PaymentService {
    @Autowired
    private TransactionTemplate transactionTemplate;
    public void transfer() {
        transactionTemplate.execute(status -> {
            // 手动控制提交或回滚
            status.setRollbackOnly();
            return null;
        });
    }
}

编程式事务灵活度高，但代码冗余，应限制在局部复杂逻辑中使用，避免全方法滥用。

经验案例：酷番云环境下的Spring事务优化实践

我们在酷番云上部署过一个电商订单系统,最初采用全注解声明式事务，但遇到两个棘手问题：

REQUIRES_NEW传播导致数据库连接池耗尽

在某积分发放逻辑中,调用了多个微服务，每个方法都使用REQUIRES_NEW，导致并发订单增加时连接数飙升。解决方案：将真正需要独立事务的写操作（如记录积分流水）单独抽取为独立Bean，仅此处使用REQUIRES_NEW，其余方法统一为REQUIRED，并将酷番云数据库连接池最大活跃数从50调至100，同时增加max-wait超时。

分布式事务与本地事务的边界混淆

部分业务同时操作MySQL与Redis,误将Redis操作也放入@Transactional中，导致事务耗时过长。解决方案：明确Redis不属于Spring事务管理范围，将缓存更新改为事务提交后的@EventListener异步执行，并利用酷番云提供的消息队列保证最终一致性。

经验总结：

• 事务粒度越细越好,但不可滥用传播行为。
• 事务只应用于持久化资源（如数据库），缓存、消息队列等应独立处理。
• 在云环境下,务必结合数据库连接池监控来调整事务超时与连接数。

事务回滚与异常处理的黄金规则

1. 运行时异常默认回滚，编译期异常默认不回滚，所以对于业务异常（如库存不足）请继承RuntimeException。
2. 捕获异常后若需要回滚,必须重新抛出，或手动调用TransactionAspectSupport.currentTransactionStatus().setRollbackOnly()。
3. 在事务中调用外部接口,应设置@Transactional(timeout = 5)，防止外部服务阻塞拖死数据库连接。

相关问答

问1：Spring的@Transactional是否支持多数据源切换？

不支持,默认@Transactional绑定单一PlatformTransactionManager，若项目中有多个数据源，需要配置多个事务管理器，并在@Transactional中通过transactionManager属性指定使用哪个管理器，@Transactional(transactionManager = "orderTransactionManager")，跨数据源的事务需要引入分布式事务方案（如Seata）。

问2：Spring事务切面的执行顺序是怎样的？

Spring声明式事务是通过AOP代理实现的,当业务方法被调用时，切面顺序为：异常处理、事务开始、业务方法执行、事务提交/回滚，最后是异常处理收尾，若存在多个切面，可以通过@Order控制顺序，但事务切面的优先级默认是Ordered.LOWEST_PRECEDENCE，即最后执行，所以业务切面（如日志、权限）会在事务开启之前运行，但如果业务切面自身抛出异常，事务不会启动，因为方法尚未进入事务切入点。

互动

如果你在实际配置Spring事务时遇到事务不生效、回滚异常或多数据源混乱等问题，欢迎在评论区留言，我会结合酷番云的环境特性和你的具体场景，给出针对性的排查思路，你的每一个真实问题，都可能成为下一篇文章的主题。