spring事务失效的几种场景以及原因
spring事务失效场景可能大家在很多文章都看过了，所以今天就水一篇，看大家能不能收获一些不一样的东西。直接进入主题
失效原因： spring事务生效的前提是，service必须是一个bean对象
解决方案： 将service注入spring
失效原因： spring默认只会回滚非检查异常和error异常
解决方案： 配置rollbackFor
失效原因： spring事务只有捕捉到了业务抛出去的异常，才能进行后续的处理，如果业务自己捕获了异常，则事务无法感知
解决方案：
1、将异常原样抛出；
2、设置TransactionAspectSupport.currentTransactionStatus().setRollbackOnly();
失效原因： spring事务切面的优先级顺序最低，但如果自定义的切面优先级和他一样，且自定义的切面没有正确处理异常，则会同业务自己捕获异常的那种场景一样
解决方案：
1、在切面中将异常原样抛出；
2、在切面中设置TransactionAspectSupport.currentTransactionStatus().setRollbackOnly();
失效原因： spring事务默认生效的方法权限都必须为public
解决方案：
1、将方法改为public；
2、修改TansactionAttributeSource,将publicMethodsOnly改为false【这个从源码跟踪得出结论】
3、开启 AspectJ 代理模式【从spring文档得出结论】
具体步骤：
1、在pom引入aspectjrt坐标以及相应插件
2、在启动类上加上如下配置
注： 如果是在idea上运行，则需做如下配置
4、直接用TransactionTemplate
示例：
失效原因： 子容器扫描范围过大，将未加事务配置的serivce扫描进来
解决方案：
1、父子容器个扫个的范围；
2、不用父子容器，所有bean都交给同一容器管理
注： 因为示例是使用springboot，而springboot启动默认没有父子容器,只有一个容器，因此就该场景就演示示例了
失效原因： 因为spring事务是用动态代理实现，因此如果方法使用了final修饰，则代理类无法对目标方法进行重写，植入事务功能
解决方案：
1、方法不要用final修饰
失效原因： 原因和final一样
解决方案：
1、方法不要用static修饰
失效原因： 本类方法不经过代理，无法进行增强
解决方案：
1、注入自己来调用；
2、使用@EnableAspectJAutoProxy(exposeProxy = true) + AopContext.currentProxy()
失效原因： 因为spring的事务是通过数据库连接来实现，而数据库连接spring是放在threadLocal里面。同一个事务，只能用同一个数据库连接。而多线程场景下，拿到的数据库连接是不一样的，即是属于不同事务
失效原因： 使用的传播特性不支持事务
失效原因： 使用了不支持事务的存储引擎。比如mysql中的MyISAM
注： 因为springboot，他默认已经开启事务管理器。org.springframework.boot.autoconfigure.jdbc.DataSourceTransactionManagerAutoConfiguration。因此示例略过
失效原因： 当代理类的实例化早于AbstractAutoProxyCreator后置处理器，就无法被AbstractAutoProxyCreator后置处理器增强
本文列举了14种spring事务失效的场景，其实这14种里面有很多都是归根结底都是属于同一类问题引起，比如因为动态代理原因、方法限定符原因、异常类型原因等
你了解的Spring 的 @Transactional 注解控制事务，失效场景知多少？
这里以 MySQL 为例，其 MyISAM 引擎是不支持事务操作的，InnoDB 才是支持事务的引擎，一般要支持事务都会使用 InnoDB。
根据 MySQL 的官方文档：
从 MySQL 5.5.5 开始的默认存储引擎是：InnoDB，之前默认的都是：MyISAM，所以这点要值得注意，底层引擎不支持事务再怎么搞都是无济于事。
如下代码所示，当前数据源若没有配置事务管理器，那也是白搭！
@Bean
public PlatformTransactionManager transactionManager(DataSource dataSource) {
return new DataSourceTransactionManager(dataSource);
}
如果此时把 @Service 注解注释掉，这个类就不会被加载成一个 Bean，那这个类就不会被 Spring 管理了，事务自然就失效了。
以下引自spring官方文档：
大致意思是：
@Transactional 只能用于 public 的方法上，否则事务会失效。如果要用在非 public 方法上，可以开启 AspectJ 代理模式。
例1：
例1 中，update方法上面没有加 @Transactional 注解，调用有 @Transactional 注解的 updateOrder 方法，updateOrder 方法上的事务管用吗？
例2：
例2 中，update方法上面加了 @Transactional 注解，调用有 @Transactional 注解的 updateOrder 方法，updateOrder 方法上的事务管用吗？
很遗憾，这两个例子中， updateOrder 方法上的事务都不管用
因为它们发生了自身调用，就是调该类自己的方法，而没有经过 Spring 的代理类，默认只有在外部调用事务才会生效，这也是老生常谈的经典问题了。
6.1这个也是出现比较多的场景：把异常吃了，然后又不抛出来，事务也不会回滚！
6.2
这样事务也是不生效的，因为默认回滚的是：RuntimeException，如果你想触发其他异常的回滚，需要在注解上配置一下，如：
@Transactional(rollbackFor = Exception.class)
这个配置仅限于 Throwable 异常类及其子类。
Propagation.NOT_SUPPORTED：表示不以事务运行，当前若存在事务则挂起。这表示不支持以事务的方式运行，所以即使事务生效也是白搭！
Spring 事务失效的7种场景
@Transactional(rollbackFor = {异常类型列表})
@EnableTransactionManagement 注解用来启用spring事务自动管理事务的功能，这个注解千万不要忘记写了。
@Transaction 可以用在类上、接口上、public方法上，如果将@Trasaction用在了非public方法上，事务将无效。
spring是通过事务管理器了来管理事务的，一定不要忘记配置事务管理器了，要注意为每个数据源配置一个事务管理器：
spring是通过aop的方式，对需要spring管理事务的bean生成了代理对象，然后通过代理对象拦截了目标方法的执行，在方法前后添加了事务的功能，所以必须通过代理对象调用目标方法的时候，事务才会起效。
看下面代码，大家思考一个问题：当外部直接调用m1的时候，m2方法的事务会生效么？
显然不会生效，因为m1中通过this的方式调用了m2方法，而this并不是代理对象，this.m2()不会被事务拦截器，所以事务是无效的，如果外部直接调用通过UserService这个bean来调用m2方法，事务是有效的，上面代码可以做一下调整，如下，@1在UserService中注入了自己，此时m1中的m2事务是生效的
重点：必须通过代理对象访问方法，事务才会生效。
spring事务回滚的机制：对业务方法进行try catch，当捕获到有指定的异常时，spring自动对事务进行回滚，那么问题来了，哪些异常spring会回滚事务呢？
并不是任何异常情况下，spring都会回滚事务，默认情况下，RuntimeException和Error的情况下，spring事务才会回滚。
也可以自定义回滚的异常类型：
当业务方法抛出异常，spring感知到异常的时候，才会做事务回滚的操作，若方法内部将异常给吞了，那么事务无法感知到异常了，事务就不会回滚了。
如下代码，事务操作2发生了异常，但是被捕获了，此时事务并不会被回滚
1.7、业务和spring事务代码必须在一个线程中
spring事务实现中使用了ThreadLocal，ThreadLocal大家应该知道吧，可以实现同一个线程中数据共享，必须是同一个线程的时候，数据才可以共享，这就要求业务代码必须和spring事务的源码执行过程必须在一个线程中，才会受spring事务的控制，比如下面代码，方法内部的子线程内部执行的事务操作将不受m1方法上spring事务的控制，这个大家一定要注意
2种方式
方式1：看日志
如果你使用了logback或者log4j来输出日志，可以修改一下日志级别为debug模式，可以看到事务的详细执行日志，帮助你定位错误
方式2：调试代码
如果你对源码比较了解，那么你会知道被spring管理事务的业务方法，执行的时候都会被TransactionInterceptor拦截器拦截，会进入到它的invoke方法中，咱们可以在invoke方法中设置一些断点，可以看到详细的执行过程，排错也就比较容易了。
整体上来说，还是需要你深入理解原理，原理了解了，写代码的时候本身就会避免很多坑。
显示推荐内容
一篇让你学会 11个Spring 失效场景
其实关于spring事务失效的场景，网络上文章介绍的不少，参差不齐。这里只分享下自己的见解，时长大概10分钟左右，先上个图介绍下。
事务方法需要定义public，非public方法事务会失效。事务拦截器TransactionalInterceptor会在执行方法前进行拦截，通过动态代理方式如果是cglib就是intercept方法或者jdk的invoke方法间接调用AbstractFallbackTransactionAttributeSource类的getTransactionAttribute方法获取配置信息，附上源码图：
进一步的跟踪getTransactionAttribute方法，我们就能看到，spring对于非public修饰的方式，返回的事务对象是null，其中allowPublicMethodsOnly返回的是一个布尔false。
事务底层使用了aop,那么也就是说通过jdk或者是cglib生成代理类，在代理类中实现的事务的功能，如果说方法是final修饰的了，那么就会导致代理类中无法重写该方法，从而导致添加事务失败。同样的如果是static的修饰的话也是无法通过动态代理变成事务方法。
简单来说就是一个方法内部调用另一个方法，但是另一个方式是有事务的，这样也会导致事务失效，因为这个调用的是this对象的方法，而不是另一个方法持有的对象，可以这里理解。
如果想要在方法内部调用另一个方法也有事务的话，就需要新建一个service对象持有。
这样，通过新建一个service方法，将事务添加到新建的service方法里就可以了。说到这里可能小伙伴觉得这样有点麻烦，那么是否有没有其他的方式不新建一个方法呢，答案是可以的，就是注入自己，利用了spring ioc内部的三级缓存的机制，这里注入自己就很好的保证了也不会出现循环依赖：
其实到了这一步，还是发现有点不太雅观，并不是说上面代码有什么问题只是觉得，可以让上面代码更加好看一点，那么有没有呢，答案是有的，是什么呢?这就不得不佩服spring强大完善的支持，那就是AopContext.currentProxy(),这个就是创建代理类，在方法调·调用前后切入，这个代理类对象是保存在ThreadLocal中的，所以通过这个代理类对象调用事务方法就能生效了。
这样看来，代码是不是就优雅多了，哈哈!!!
这里需要明确一个前提，就是使用spring事务的前提，就是对象要被spring管理就需要创建bean实例，在开发中，我们都是通过@Controller,@Service,@Component,@Repository等注解自动的实现依赖注入实例化的功能，但假如说在相应的控制层，业务层，数据层忘记加相应的注解，那么也是会失效的。因为没有交给spring管理，例如：
回想起前几年配置事务管理器时，都会有这样的一段配置：
通过这一段配置也可以知道，其实spring事务就是通过数据库连接事务多线程连接会导致持有的connetion不是同一个，从网上找了一张图，通过这张图进一步理解：
接着附上伪代码结合上面的图进一步理解：
事务add方法中调用了另一个事务doOtherThing,但是事务方法是在另一个线程中调用的，这样就会导致两个方法不在同一个线程中，获取到的数据库链接不一样，是两个不同的事务，一旦doOtherThing发生异常，add方法也是不可能发生回滚的.这里需要解释以下什么是同一个事务，也就是说只有拥有同一个数据库连接才能同时提交和回滚。如果在不同的线程，拿到的数据库连接肯定是不一样的，所以是不同的事务。
这个就没什么好讲的了，也就是innodb和myisam引擎的不同，5版本以前默认是myisam引擎，这个引擎是不支持事务的，5版本以后的innodb是支持事务的。
这个其实可能也是比较容易忽略的，因为我们印象里好像没怎么配置过怎么开启事务，也确实是这样哈，为什么?其实原因很简单，springboot项目通过DataSourceTransactionManagerAutoConfiguration这个类已经默默的为我们开启了事务。
这个类会加载spring.datasource这个配置文件从而启动事务，如果是非springboot项目就需要自己手动在xml文件中配置事务管理器。
类似这样的从而开启事务。
在使用@Transactional注解时，是可以指定propagation参数的，该参数是用来指定事务的传播特性，其中只有required,requires_new,nested这三种才会创建新事务：
像上面的Propagation.NEVER这种类型的传播特性不支持事务，如果有事务则会抛异常。
像这种手动try...catch了异常，又没有手动抛出，那么sring就会认为程序是异常的就不会回滚了。
捕获了异常又抛出了exception异常，事务同样不会回滚，因为spring事务默认情况下只会回滚RuntimeException(运行时异常)和Error(错误)，对于普通的Exception(非运行时异常)，不会回滚，网上找了一张图：
这里exception里除了分为运行时异常和非运行时异常(ioException)。
1） 让checked例外也回滚：
在整个方法前加上 @Transactional(rollbackFor=Exception.class)
2） 让unchecked例外不回滚：
@Transactional(notRollbackFor=RunTimeException.class)
3）不需要事务管理的(只查询的)方法：@Transactional(propagation=Propagation.NOT_SUPPORTED)
这里需要提及的一句是，如果是自定义了的异常，比如说我自定义了DALException异常，那么就应该是@Transactional(notRollbackFor=DALException.class)，一旦抛出的异常不属于DALException异常，那么事务也是不会生效的。
其实这个就有点像是js里的冒泡事件，可能我只是需要底部，结果外层窗口事件也触发了，联想到事务这里，那么也是一样的，嵌套多个可能只是想回滚对应的事务，就不用把其他事务也回滚了，这个可以通过try...catch来处理，将需要处理回滚的事务放这里面就不会把外层的也会滚了。