Spring事务失效排查与解决指南

大家好，我们又见面了啊~本文《Spring事务失效排查与解决全攻略》的内容中将会涉及到等等。如果你正在学习文章相关知识，欢迎关注我，以后会给大家带来更多文章相关文章，希望我们能一起进步！下面就开始本文的正式内容~

Spring事务失效的核心原因在于AOP代理机制未生效、传播行为配置不当或异常处理不正确。1. 自调用问题导致代理失效，解决方式是分离方法到不同Service、注入自身代理或使用AopContext；2. 事务传播行为需根据场景选择，如REQUIRED（默认）、REQUIRES_NEW或NESTED；3. 回滚规则需明确指定rollbackFor，避免异常被吞导致回滚失败。

Spring事务失效这事儿，说实话，挺让人头疼的。它不是什么玄学，究其根本，无非就是Spring的AOP代理机制没能按你设想的那样工作，或者事务的传播行为、回滚规则没理解透彻，再或者就是代码里不经意间把异常给“吞”了。解决它，关键在于深入理解Spring事务的底层原理，然后对照你的具体场景，一步步排查。

解决方案

排查Spring事务失效问题，需要从几个核心点入手：

1. 代理机制未生效： Spring事务是基于AOP代理实现的。如果你的方法调用没有经过代理，事务自然不会生效。最典型的就是“自调用”问题，即同一个类中的方法A调用方法B，如果方法B有事务注解，但方法A没有，或者方法A通过this.methodB()直接调用，那么方法B的事务注解是不会被拦截到的。此外，非public方法、final方法或static方法，以及未被Spring容器管理的类，其事务注解也不会生效。
2. 事务传播行为配置不当： @Transactional注解的propagation属性定义了事务的传播行为。如果父子事务的传播行为配置不合理，比如一个方法需要独立事务（REQUIRES_NEW），但却配置成了依赖父事务（REQUIRED），或者反之，都可能导致事务行为不符合预期。
3. 异常类型与回滚规则： Spring事务默认只对RuntimeException和Error进行回滚。如果你的业务逻辑抛出的是Checked Exception（受检异常，如IOException），但又没有通过@Transactional(rollbackFor = MyCheckedException.class)明确指定回滚，那么事务就不会回滚。
4. 异常被捕获与吞噬： 这是个非常常见的陷阱。如果在事务方法内部使用了try-catch块捕获了异常，但没有重新抛出（或者抛出的是一个非RuntimeException且未配置rollbackFor的异常），Spring事务管理器就无法感知到异常的发生，从而认为事务是成功的，不会触发回滚。
5. 数据库引擎不支持事务： 这是一个比较基础但偶尔会被忽略的问题。例如，MySQL的MyISAM引擎就不支持事务，只有InnoDB等引擎才支持。

为什么我的内部方法调用事务会失效？

这是个老生常谈的问题，很多人都会踩到这个坑。当你在一个Spring Bean里，比如ServiceA，有一个方法methodA()，它内部直接调用了同一个类里的另一个方法methodB()，而methodB()上加了@Transactional注解，你会发现methodB()的事务根本没生效。

原因很简单，Spring的AOP（面向切面编程）是基于代理实现的。当你通过@Autowired注入ServiceA时，你拿到的是ServiceA的一个代理对象。当你调用serviceA.methodA()时，这个调用会先经过代理层，代理层会检查methodA是否有事务注解，然后执行相应的事务逻辑。

但当methodA()内部通过this.methodB()来调用methodB()时，这个调用是直接发生在ServiceA的原始对象上的，它绕过了Spring为ServiceA创建的那个代理对象。换句话说，methodB()上的@Transactional注解所对应的事务切面根本没有机会被执行到。这就是所谓的“自调用事务失效”问题。

解决办法其实有几种：

• 分离方法到不同的Service： 这是最推荐也最清晰的做法。把methodB()移到一个独立的ServiceB中，然后ServiceA通过@Autowired注入ServiceB，再调用serviceB.methodB()。这样，serviceB的调用自然会经过其代理，事务就能生效了。

• 注入自身代理： 你可以在ServiceA中注入ServiceA的代理对象。比如：

  @Service
  public class ServiceA {
      @Autowired
      private ServiceA self; // 注入自身的代理
  
      @Transactional
      public void methodA() {
          // ... 业务逻辑
          self.methodB(); // 通过代理调用methodB
      }
  
      @Transactional
      public void methodB() {
          // ... 业务逻辑
      }
  }

  需要注意的是，这种方式需要在Spring配置中开启exposeProxy = true，比如在@EnableAspectJAutoProxy(exposeProxy = true)。

• 使用AopContext.currentProxy()： 类似注入自身代理，但更直接：

  @Service
  public class ServiceA {
      @Transactional
      public void methodA() {
          // ... 业务逻辑
          ((ServiceA) AopContext.currentProxy()).methodB(); // 通过当前代理调用
      }
  
      @Transactional
      public void methodB() {
          // ... 业务逻辑
      }
  }

  同样需要exposeProxy = true。我个人觉得，虽然这种方式能解决问题，但代码看起来有点怪，可读性稍差。

事务回滚不生效，是异常没处理对吗？

是的，很多时候，事务回滚不生效，就是因为异常处理没到位。Spring事务的默认回滚规则是，只对RuntimeException（运行时异常）和Error进行回滚。对于Checked Exception（受检异常），Spring事务默认是不会回滚的。

举个例子，如果你在一个事务方法里，抛出了一个IOException，而你没有显式地告诉Spring这个IOException需要回滚，那么事务就不会回滚。要让它回滚，你需要这样配置：

@Transactional(rollbackFor = IOException.class)
public void doSomethingWithError() throws IOException {
    // 业务逻辑，可能会抛出IOException
    throw new IOException("文件操作失败");
}

更常见也更隐蔽的问题是，你“吞噬”了异常。 想象一下这样的代码：

@Transactional
public void doSomethingTransactional() {
    try {
        // 可能会抛出RuntimeException，比如 NullPointerException
        int result = 10 / 0; // 制造一个运行时异常
        // ... 其他业务逻辑
    } catch (Exception e) {
        // 仅仅打印日志，没有重新抛出异常
        System.err.println("发生错误：" + e.getMessage());
        // 事务管理器此时认为方法正常结束，不会回滚
    }
}

在这种情况下，尽管内部发生了RuntimeException，但由于try-catch块捕获了它，并且没有重新抛出任何RuntimeException或Error，Spring事务管理器在方法执行完毕后，并不知道有异常发生，它会认为方法执行成功了，因此事务会正常提交，数据不会回滚。

正确的做法是： 如果你在事务方法内部捕获了异常，并且希望事务回滚，你必须重新抛出一个RuntimeException，或者一个你在rollbackFor中指定了的异常。

@Transactional
public void doSomethingTransactionalCorrectly() {
    try {
        int result = 10 / 0;
    } catch (Exception e) {
        System.err.println("发生错误，准备回滚：" + e.getMessage());
        // 重新抛出运行时异常，强制事务回滚
        throw new RuntimeException("业务处理失败，事务回滚", e);
    }
}

或者，如果你想对特定的受检异常回滚：

@Transactional(rollbackFor = MyBusinessException.class)
public void doSomethingWithCustomException() throws MyBusinessException {
    try {
        // ... 业务逻辑
        if (someCondition) {
            throw new MyBusinessException("自定义业务异常");
        }
    } catch (MyBusinessException e) {
        // 捕获并重新抛出，或者直接抛出
        throw e;
    }
}

记住，事务管理器只有在方法正常退出（没有抛出指定回滚的异常）或异常退出（抛出了指定回滚的异常）时，才能决定是提交还是回滚。你中间把异常“消化”了，它就无从判断了。

事务传播行为那么多，我到底该怎么选？

Spring事务传播行为确实挺多的，初学者很容易混淆。但实际开发中，最常用、也最需要理解透彻的其实就那么几个。理解它们的本质，能帮你避开很多坑。

• REQUIRED (默认值)： 这是最常用的。如果当前存在事务，则加入该事务；如果当前没有事务，则创建一个新的事务。绝大多数业务方法都应该使用这个传播行为。它保证了方法总是在一个事务中运行。
  • 场景： 订单创建、用户注册等，这些操作通常是整个业务流程的一部分，需要在一个统一的事务中。
• REQUIRES_NEW： 总是创建一个新的事务。如果当前存在事务，则挂起当前事务。这个新的事务有自己的独立提交和回滚范围，与外部事务互不影响。
  • 场景： 审计日志、消息发送等“独立”操作。比如，你有一个复杂的业务流程，其中一个步骤是记录日志，即使主业务流程失败回滚了，你可能也希望日志记录能成功提交。这时候，日志记录方法就可以使用REQUIRES_NEW。
  • 坑点： REQUIRES_NEW创建的新事务，即使它自己提交了，如果外部的父事务最终回滚了，这个REQUIRES_NEW的事务是不会被父事务回滚的。反之，如果REQUIRES_NEW的事务自己回滚了，它也不会影响外部父事务的提交或回滚（除非它向上抛出了异常，导致父事务也捕获到并决定回滚）。
• NESTED： 如果当前存在事务，则在嵌套事务内执行。如果没有事务，则行为与REQUIRED一样。嵌套事务是“逻辑上”的嵌套，它通过数据库的保存点（Savepoint）实现。当内层事务回滚时，可以回滚到保存点，而不会影响外层事务。但如果外层事务回滚，内层事务也会跟着回滚。
  • 场景： 复杂的业务流程中，你希望某个子操作可以独立回滚，但又不希望它完全脱离主事务。比如，在一个大订单处理中，某个子商品的库存扣减失败了，你只想回滚这个子商品的扣减，而不是整个订单。
  • 限制： NESTED需要底层JDBC驱动和数据库支持保存点，并不是所有数据库都完全支持。

如何选择？

• 默认选择REQUIRED。 它是最安全、最符合直觉的。它能确保你的一系列数据库操作要么全部成功，要么全部失败。
• 当需要“独立”操作时，考虑REQUIRES_NEW。 这种独立性意味着它的提交或回滚不受外部事务的影响。
• 当需要“部分回滚”且数据库支持时，考虑NESTED。 但这个相对复杂，也用得较少。

至于SUPPORTS、NOT_SUPPORTED、NEVER、MANDATORY，它们在实际业务代码中用得相对较少，或者说，如果你不是在做一些非常特殊的底层框架或集成，通常不需要过多关注。SUPPORTS表示支持当前事务，没有就非事务执行；NOT_SUPPORTED表示总是非事务执行；NEVER表示不能有事务，有就抛异常；MANDATORY表示必须有事务，没有就抛异常。理解了REQUIRED、REQUIRES_NEW和NESTED，基本就能应对90%以上的场景了。

以上就是《Spring事务失效排查与解决指南》的详细内容，更多关于的资料请关注golang学习网公众号！