spring事务失效的核心原因在于aop代理机制未生效、传播行为配置不当或异常处理不正确。1. 自调用问题导致代理失效，解决方式是分离方法到不同service、注入自身代理或使用aopcontext；2. 事务传播行为需根据场景选择，如required（默认）、requires_new或nested；3. 回滚规则需明确指定rollbackfor，避免异常被吞导致回滚失败。
Spring事务失效这事儿，说实话，挺让人头疼的。它不是什么玄学，究其根本，无非就是Spring的AOP代理机制没能按你设想的那样工作，或者事务的传播行为、回滚规则没理解透彻，再或者就是代码里不经意间把异常给“吞”了。解决它，关键在于深入理解Spring事务的底层原理，然后对照你的具体场景，一步步排查。
解决方案
排查Spring事务失效问题，需要从几个核心点入手：
代理机制未生效： Spring事务是基于AOP代理实现的。如果你的方法调用没有经过代理，事务自然不会生效。最典型的就是“自调用”问题，即同一个类中的方法A调用方法B，如果方法B有事务注解，但方法A没有，或者方法A通过this.methodB()直接调用，那么方法B的事务注解是不会被拦截到的。此外，非public方法、final方法或static方法，以及未被Spring容器管理的类，其事务注解也不会生效。事务传播行为配置不当： @Transactional注解的propagation属性定义了事务的传播行为。如果父子事务的传播行为配置不合理，比如一个方法需要独立事务（REQUIRES_NEW），但却配置成了依赖父事务（REQUIRED），或者反之，都可能导致事务行为不符合预期。异常类型与回滚规则： Spring事务默认只对RuntimeException和Error进行回滚。如果你的业务逻辑抛出的是Checked Exception（受检异常，如IOException），但又没有通过@Transactional(rollbackFor = MyCheckedException.class)明确指定回滚，那么事务就不会回滚。异常被捕获与吞噬： 这是个非常常见的陷阱。如果在事务方法内部使用了try-catch块捕获了异常，但没有重新抛出（或者抛出的是一个非RuntimeException且未配置rollbackFor的异常），Spring事务管理器就无法感知到异常的发生，从而认为事务是成功的，不会触发回滚。数据库引擎不支持事务： 这是一个比较基础但偶尔会被忽略的问题。例如，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的代理对象。比如：
@Servicepublic 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()： 类似注入自身代理，但更直接：
@Servicepublic 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("文件操作失败");}
更常见也更隐蔽的问题是，你“吞噬”了异常。 想象一下这样的代码：
@Transactionalpublic 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中指定了的异常。
@Transactionalpublic 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事务失效问题详细排查与解决方法的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/141365.html
微信扫一扫 
支付宝扫一扫 
