Spring事务失效的隐蔽陷阱与排查清单

在 Java 后端开发中，Spring 声明式事务（@Transactional）是保证数据一致性的利器。然而，许多开发者都遇到过“事务明明写了注解，却莫名失效”的诡异场景。这种问题往往不是配置错误，而是源于 Spring 的代理机制与业务代码交互的边界条件。本文将深入剖析这些隐蔽陷阱，并提供一套系统化的排查清单。

1. 代理机制：事务的基石与失效的根源

Spring 的事务管理基于 AOP（面向切面编程）实现。当我们为某个 Bean 方法标注 @Transactional 后，Spring 容器在初始化时不会直接使用原始 Bean，而是创建一个代理对象。这个代理对象在方法调用前后插入事务开启、提交、回滚等逻辑。理解代理机制是掌握事务行为的前提，也是后续所有失效场景的底层根源。

Spring 的事务代理主要基于两种方式：JDK 动态代理（面向接口）与 CGLIB 代理（面向类）。JDK 动态代理只能代理接口，生成的代理类实现了原接口，并将方法调用委托给 InvocationHandler。CGLIB 则通过生成目标类的子类来实现代理，因此可以代理没有接口的类。Spring Boot 2.x 之后默认使用 CGLIB 代理（spring.aop.proxy-target-class=true），但很多遗留项目仍采用 JDK 动态代理。

代理对象的创建时机发生在 Bean 初始化后期，通过 BeanPostProcessor（如 AbstractAutoProxyCreator）完成。默认情况下，只有标识了 @Transactional（或满足其他 AOP 条件）的 Bean 才会被代理。若类内部方法调用，则不会经过代理对象，这是理解事务失效的关键。

设计上，基于代理的事务天然无法拦截“内部调用”与“私有方法”，这是因为代理对象包裹的是外部调用者的视角，而内部 this 调用直接指向原始对象。这种设计取舍保证了 Spring 事务的无侵入性，但也要求开发者遵循“通过代理调用”的原则。

举个例子，假设我们有如下接口与实现：

public interface UserService {
    void createUser(User user);
}

@Service
public class UserServiceImpl implements UserService {
    @Transactional
    public void createUser(User user) {
        // 存库操作
    }
}

当从外部注入 UserService 并调用 createUser 时，调用的实际上是代理对象。但若在该实现类的另一个方法中直接调用 createUser（通过 this），则不会触发事务。下面的时序图描述了两种调用路径：

外部调用者 -> 代理对象(JDK或CGLIB) -> 原始对象方法 (事务生效，代理开启事务/提交/回滚)

内部调用 (this.createUser) -> 直接进入原始对象方法 (事务失效，因为代理未介入)

2. 自调用：最经典的失效陷阱

自调用指的是在同一个类内部，一个方法直接调用另一个被 @Transactional 标注的方法。由于 Spring 的 AOP 代理机制，内部调用不会经过代理，因此事务注解不会生效。例如：

@Service
public class OrderService {
    @Transactional
    public void createOrder(Order order) {
        // 保存订单
    }

    public void processOrder(Order order) {
        validate(order);
        this.createOrder(order); // 自调用，事务不生效
        updateStock(order); // 若 createOrder 失败，可能回滚失败
    }
}

在此例子中， processOrder 方法本身没有事务注解，内部调用 createOrder 时，事务切面并未触发。如果 createOrder 执行过程中抛出了运行时异常，事务不会回滚，因为当前根本没有事务上下文。这可能导致数据不一致：订单已保存而库存未更新，若库存更新失败，整个操作“看起来”应该全部成功，但实际上却只部分成功。

解决自调用问题有多种方案，最直接的是将事务方法拆分到另一个 Bean 中，例如单独建立一个 OrderTransactionService，并在其中声明事务方法。另一种方案是在原类中注入自身（循环依赖问题在 Spring 中可通过三级缓存解决，但需要谨慎），或者使用 AopContext.currentProxy() 获取当前代理对象。

一个优雅的改造方式是使用 @Resource 注入自身的代理：

@Service
public class OrderService {
    @Autowired
    private OrderService self; // 注入自身代理

    @Transactional
    public void createOrder(Order order) { ... }

    public void processOrder(Order order) {
        self.createOrder(order); // 调用代理方法
    }
}

但这种注入自身的模式在构造器注入时会陷入死循环，推荐用 setter 注入或 @Lazy 注解。此外，若类没有接口，建议使用 CGLIB 代理，并可使用 AopContext 方法。但请注意，使用 AopContext 需要在配置中开启 exposeProxy=true。

@EnableTransactionManagement(exposeProxy = true)
// 然后在方法中使用
((OrderService) AopContext.currentProxy()).createOrder(order);

尽管 AopContext 方法也能解决，但代码可读性较差，并不推荐在常规业务中使用，仅在确实需要时作为应急手段。

3. 基于接口与基于类的代理差异

Spring 的事务代理策略选择取决于目标 Bean 是否实现了接口。当使用 JDK 动态代理时，Spring 要求 Bean 至少实现一个接口，代理类会实现这些接口，并将方法调用转发给 InvocationHandler。此时，如果我们在类内部直接 this 调用，一定不会经过代理。

CGLIB 代理则不同，它直接生成目标类的子类，因此可以拦截非 final 的 public 方法（private 和 final 方法不行）。这带来一个重要区别：在使用 CGLIB 且没有接口时，若类中的方法调用自身，仍然不会经过代理，因为调用发生在原始对象内部。

下表对比了两种代理方式在事务上的异同：

当你在代码中注入的是接口类型时，Spring 会使用 JDK 动态代理；当类没有接口（或配置强制 CGLIB）时，则使用 CGLIB。Spring Boot 2.x 默认强制 CGLIB，因此即使有接口也会使用 CGLIB。这意味着如果方法被 final 修饰，CGLIB 无法重写，事务也会失效。

例如以下代码在使用 CGLIB 时，final 方法中的事务不会生效：

@Service
public class PayService {
    @Transactional
    public final void payMoney() { // 无法被代理重写
        // 事务不会生效
    }
}

因此，在编写事务方法时，应避免使用 final 修饰，并尽量将事务逻辑放在 public 方法中。同时，私有方法上的 @Transactional 也会被忽略，因为代理无法访问私有成员——即使通过反射也不行（CGLIB 不会代理 private 方法）。

4. 异常吞没：回滚失效的元凶

事务回滚的触发条件是方法抛出运行时异常（RuntimeException）、错误（Error）或满足回滚规则的异常。如果我们在事务方法中捕获了异常并正常返回，事务会认为操作成功，从而提交。这是实际项目中最常见的导致“数据不一致”的原因，我们称之为异常吞没。

来看一个典型示例：

@Transactional
public void createCustomer(Customer customer) {
    try {
        customerRepository.save(customer);
        // 其他操作
    } catch (Exception e) {
        log.error("保存失败", e);
        // 没有抛出，事务继续提交
    }
}

当 catch 到异常后，方法正常结束，Spring 会认为事务成功并执行提交。但底层的数据库操作可能已失败，然而由于异常被吞掉，数据库连接不会回滚。这会导致部分数据已写入，但业务逻辑却认为这是不完整的。实际上，如果 customerRepository.save 抛出异常，数据库操作本身可能未执行，异常吞掉后，方法退出，事务提交，但没有执行任何修正。若前面有其他数据库操作，则它们会被提交。

要避免这类问题，必须确保在需要回滚的场景中，让异常向上传播。如果你希望保留部分逻辑，可以采用编程式事务，或在 catch 块中显式回滚。例如：

@Transactional
public void updateAccount() {
    try {
        // 执行更新
        accountRepository.update(...);
        // 执行消息发送
        sendMessage();
    } catch (Exception e) {
        // 手动回滚
        TransactionAspectSupport.currentTransactionStatus().setRollbackOnly();
        // 或者直接抛异常
        throw new RuntimeException("操作失败", e);
    }
}

然而，最规范的做法是不要 catch 所有异常。仅捕获需要处理的预期异常，并重新抛出带有业务含义的异常，以触发事务回滚。下列表格对比了不同处理方式的效果：

这里引入另一个关键点：Spring 默认只对 RuntimeException 和 Error 进行回滚，对受检异常（checked exception）不回滚。如果业务方法抛出 IOException 这类受检异常，事务仍会提交。

5. 事务传播行为：边界与误用

Spring 定义了多种事务传播行为，用于控制事务方法之间的事务边界。默认是 REQUIRED，即当调用方存在事务时，方法直接加入当前事务；若不存在则新建。若使用不当，可能造成部分逻辑不在预期的事务范围内。

例如，REQUIRES_NEW 会挂起当前事务并新建一个事务，但新事务的提交和回滚与外部事务无关。如果内部事务失败但外部事务成功，外部事务仍会提交其已做的数据库操作，这可能导致部分更新。反之，若内部事务成功但之后外部事务回滚，那么内部事务的提交仍然是持久的吗？实际上是会的（如果内部事务已提交），则可能留下中间状态。

传播行为中还有一个易被误用的 REQUIRES_NEW 场景：当外部方法有事务，内部方法标注 REQUIRES_NEW 时，Spring 会暂停外部事务连接，并开启新连接。这常被用于日志记录或事件发送，但若在业务核心路径使用，可能会引发性能问题或数据不一致。

下表总结了常用传播行为的事务边界：

此外，当在同一个类中调用传播行为不同的事务方法时（即自调用），即使标注了 REQUIRES_NEW，也不会生效，因为代理未介入。这会导致本应新建的事务实际合并到外层（若外层有事务）或根本无事务。

6. 事务管理器与数据源：配置细节

Spring 事务需要正确配置 TransactionManager。在实际开发中，很多事务失效是因为未创建合适的 PlatformTransactionManager Bean。在 Spring Boot 中，如果 classpath 下存在单个 DataSource，Spring Boot 会自动配置 DataSourceTransactionManager；但若引入多个数据源（如读写分离），则必须显式指定主事务管理器。

当多个数据源并存时，若 @Transactional 没有指定事务管理器，Spring 会尝试在容器中寻找唯一的 TransactionManager；若存在多个，则需用 transactionManager 属性指定：

@Transactional(transactionManager = "orderTransactionManager")
public void orderTransaction() { }

另一个常见问题是在非 Spring 管理的连接上执行事务。例如，在 Filter 或 Listener 中手动获取连接并使用编程式事务，则 Spring 的声明式事务无法拦截。

此外，事务还可以基于 JTA（Java Transaction API）或 JPA。不同持久层技术的异常体系也有差异，例如 JPA 抛出 TransactionRequiredException 等，在回滚判断上要格外注意。Spring 会处理这些底层异常，将其转换为 DataAccessException。

7. 事务失效的其他隐蔽场景

除了自调用和异常吞没外，还有一些容易被忽视的隐藏场景。例如，被 final 修饰的方法无法被 CGLIB 代理，因此事务失效；或者 Bean 本身不是 Spring 管理的（如 new 出来的对象），则注解完全不会生效。

另一个高频坑点与线程相关：如果在一个事务方法中开启了新线程执行数据库操作，那么新线程中的操作不在原事务内（因为事务与线程绑定），它要么无事务，要么需要自己开启新事务。下面的流程图解释了线程与事务的关系：

主线程: 开启事务 -> 执行 DB 操作 -> 提交/回滚
        |
        | 启动新线程
        v
子线程: 无事务 (默认) 或 REQUIRES_NEW 新开事务

这意味着，如果事务方法内部异步调用另一个本应参与同一事务的方法吗，该操作将不受原事务控制。如果需要异步且保证一致性，可以考虑使用消息队列等可靠方案。

此外，使用 @Transactional 的类若实现了多个接口，且代理基于 JDK，那么只有接口中定义的方法才会被代理。如果某方法只存在于实现类中，调用该方法的接口没有声明它，那么外界的接口引用调用不到该方法，自然也就没有事务。

8. 常见误区

很多开发者以为只要在方法上加了 @Transactional，就万事大吉了。实际上，注解本身只是“请求” Spring 对调用进行包装，但它依赖于代理是否真正介入。常见的误区包括：

• 误认为 try/catch 后事务也可回滚，但实际上异常必须传播出去。
• 误认为私有方法上的 @Transactional 有效，实际会被忽略。
• 误认为同一个类内部方法调用，事务会因 REQUIRES_NEW 而生效，实际不会。
• 误认为受检异常也会触发回滚，需要 rollbackFor 指定。

下面的表格列举了几个常见误区与事实：

9. 生产实践建议

为了避免事务问题，建议在工程中遵循以下实践准则：

第一，事务方法一律放在 public 且非 final 的方法上，确保代理可拦截。将事务逻辑集中在 Service 层，避免跨层事务混乱。

第二，避免自调用，设计时将事务方法放在独立的 Bean 中，或通过注入自身代理来实现调用。这样既清晰又可靠。

第三，异常处理遵循“抛得早，捕得晚”原则。不要在事务方法内部吃掉关键异常，如果确实要捕获，必须使用 rollbackFor 明确回滚条件，或者直接抛出 RuntimeException。

第四，在写任何事务代码前，审查是否有数据库连接泄漏、连接池耗尽等问题。确保事务快进快出，避免长事务。

对于复杂的业务上下文，可以采用编程式事务模板（TransactionTemplate）进行精细控制。例如：

@Service
public class OrderService {
    private final TransactionTemplate transactionTemplate;

    public void createOrder() {
        transactionTemplate.execute(status -> {
            try {
                // DB 操作
            } catch (Exception e) {
                status.setRollbackOnly();
            }
            return null;
        });
    }
}

10. 排障清单

当怀疑事务失效时，按照以下清单排查，能快速定位问题根源。

同时，可以通过日志或调试确认代理对象。打印注入的 bean 的 class 名称，一般包含 $$EnhancerBySpringCGLIB 或 Proxy。在代码中可临时输出：

System.out.println(bean.getClass());

如果输出的是原始类，说明没有代理，自然事务不会生效。

11. 面试/复盘问题

事务失效相关问题是面试官喜爱考察的点，也是复盘项目成败的关键。以下问题可以帮助你检验理解和查漏补缺：

1. Spring 事务默认在什么异常下回滚？如何配置受检异常回滚？
2. 为什么 self-invocation 会失效？有哪些解决方案？
3. JDK 动态代理与 CGLIB 在实现上有什么区别？对 final 方法的影响是什么？
4. 如果一个事务方法调用了另一个事务方法（都通过外部代理），传播行为默认是什么？此时事务是同一个吗？
5. 在 try/catch 中捕获异常后抛出新的 RuntimeException，事务会回滚吗？
6. 当你在一个事务方法中调用 this.method()，这里的 this 是代理对象还是原始对象？
7. Spring Boot 2 默认使用哪种代理？为什么？
8. 什么是 REQUIRES_NEW？它可能带来什么数据一致性风险？
9. 如果数据源配置了多个，如何确保事务管理器选对？

12. 总结

事务失效问题看似隐蔽，但只要理解代理机制与异常传播规则，就能逐一破解。核心要点是：Spring 事务靠 AOP 代理介入，因此必须确保调用途径经过代理、方法可被代理、异常能够触发回滚。从设计上，尽量将事务方法与业务入口分离，避免自调用；在异常处理上，避免吞异常；在配置上，确保事务管理器正确。

本文给出的排查清单与建议，在实际项目中能快速定位多数问题。记住一个简单的自检口诀：方法是否 public？调用是否走代理？异常是否抛得出去？通过这三问，绝大多数事务失效之谜都能解开。在复杂的分布式系统中，更要权衡好事务边界与一致性需求，避免因为追求强一致而陷入长事务的泥潭。

以上就是Spring事务失效的隐蔽陷阱与排查清单的详细内容，更多关于Spring事务失效陷阱与排查的资料请关注脚本之家其它相关文章！