Spring 事务失效可能是哪些原因？

2026年02月03日

面试考察点

面试官提出这个问题，通常想考察以下几个层面：

对 Spring 声明式事务原理的理解深度： 不仅仅是会用 @Transactional 注解，更要知道它是基于 AOP（面向切面编程）和动态代理实现的。失效的根本原因往往源于对此机制理解不透彻。
实战经验与 “踩坑” 能力： 面试官希望了解你是否在实际开发中遇到过事务问题，能否识别并解决常见的配置和编码陷阱。
系统性的排查思路： 面对事务失效，能否提供一套从浅入深、从配置到代码的排查逻辑。
对事务传播行为和隔离级别的理解： 是否能将抽象的概念与具体的失效场景联系起来。

核心答案

Spring 事务失效的核心原因是其声明式事务的 AOP 代理机制未能按预期对目标方法进行增强。常见原因可归结为以下几类：

数据库/存储引擎不支持事务（如 MySQL 的 MyISAM）。
@Transactional 注解的方法不是 public。
方法自调用（同一个类中，一个非事务方法调用另一个 @Transactional 方法）。
捕获了异常且未重新抛出，或抛出的异常类型未被 @Transactional 配置回滚。
事务传播行为配置不当（如期望新事务但配置了 SUPPORTS）。
Bean 未被 Spring 容器管理，或使用了错误的 @Transactional 注解包。
在多线程环境下，事务上下文无法传播。
在 try-catch 块中，手动 setRollbackOnly 后依然提交（编程式事务场景）。

深度解析

原理/机制

Spring 声明式事务的本质是 AOP 动态代理。当我们给一个方法标注 @Transactional 后，Spring 会在运行时为目标对象创建一个代理对象。当我们调用该方法时，实际调用的是代理对象的方法。代理方法会开启事务、执行目标方法、根据执行情况提交或回滚事务。

任何导致代理逻辑未被执行或执行流程被 “短路” 的情况，都会造成事务失效。理解了这一点，就能看透大部分失效场景。

代码示例与典型场景分析

下面通过几个典型代码片段来说明：

场景一：自调用问题（最常见）

@Service
public class OrderService {
    public void createOrder(Order order) {
        // 一些业务逻辑...
        this.deductInventory(order.getProductId(), order.getQuantity()); // 自调用，事务失效！
    }

    @Transactional(rollbackFor = Exception.class)
    public void deductInventory(Long productId, int quantity) {
        // 扣减库存的数据库操作
        inventoryMapper.reduceStock(productId, quantity);
    }
}

原因： createOrder 方法调用的是 this（即目标对象本身）的 deductInventory 方法，而非其代理对象的方法，因此事务增强逻辑完全被绕过。

场景二：异常处理不当

@Transactional
public void updateData(Data data) {
    try {
        dataMapper.update(data);
        int i = 1 / 0; // 会抛出 ArithmeticException
    } catch (Exception e) {
        // 捕获了异常，且没有重新抛出！
        log.error("更新数据失败", e);
        // 事务管理器认为方法执行成功，将提交事务
    }
}

原因： 默认情况下，@Transactional 只在遇到 RuntimeException 和 Error 时才回滚。这里虽然抛出了 RuntimeException，但被 catch 后未重新抛出，代理逻辑认为方法正常结束，因此提交事务。即使你配置了 rollbackFor = Exception.class，被捕获后不抛出也一样无效。

对比分析与注意事项

PROPAGATION_REQUIRED vs PROPAGATION_REQUIRES_NEW: 前者加入当前事务，后者挂起当前并创建新事务。如果错误地期望在外部事务回滚时，内部事务独立提交，却使用了 REQUIRED，就会导致数据不一致，这可以看作一种 “逻辑上的失效”。
@Transactional 注解放置： 放在接口方法上还是实现类方法上？在 Spring AOP 使用 JDK 动态代理时，放在接口上是安全的；使用 CGLIB 代理时，可以放在类上。最佳实践是统一放在实现类的具体方法上，以避免混淆。

最佳实践

明确指定 rollbackFor: 建议设置为 @Transactional(rollbackFor = Exception.class)，避免因检查异常导致不回滚。
指定事务管理器： 在多数据源场景下，使用 @Transactional(value = “txManagerName”) 明确指定。
将事务方法尽可能独立： 避免自调用。如需自调用，可通过 AopContext.currentProxy()（需开启 exposeProxy）或从容器中重新获取 Bean 的方式来调用代理方法。
事务方法保持简短： 不要在事务方法中执行耗时操作（如 RPC 调用、文件 IO），这会长时间持有数据库连接，影响性能。
正确的异常处理： 如果事务方法内必须 try-catch，务必在 catch 块中 throw new RuntimeException(e) 或手动 TransactionAspectSupport.currentTransactionStatus().setRollbackOnly()。

常见误区

误区一：“我用了 @Transactional，方法里所有数据库操作就都在一个事务里了。” —— 错。这取决于传播行为。如果方法内部调用了另一个 REQUIRES_NEW 的方法，就会开启新事务。
误区二：“在 Controller 层加 @Transactional 也可以。” —— 不推荐。事务边界应定义在服务层，Controller 层应关注请求调度和响应封装。
误区三：“异步方法里加 @Transactional 有用。” —— 通常无效。因为异步方法会在新线程中执行，而 Spring 的事务信息是通过 ThreadLocal 存储的，默认无法跨线程传播。

总结

Spring 事务失效的核心在于其 AOP 代理机制被破坏，主要排查方向是：检查方法是否为 public、避免自调用、正确处理异常、确保数据库支持、并理解事务传播行为的实际效果。掌握这些，你就能从容应对大部分事务相关的问题。

发布于2026年02月03日|12:54:04