spring中事务失效场景和循环依赖问题

一、spring中事务失效场景
1、抛出检查异常导致事务不能正确回滚
原因：spring默认只会回滚（runtimeException和Error子类） 非检查异常
解法：配置rollbackFor 属性 为Exception.calss

2、业务方法内自己try-catch异常 导致事务不能正常回滚
原因：事务通知只有捉到了目标抛出的异常，才能进行后续的回滚处理，如果目标自己处理掉异常，事务通知无法知悉
解法1：异常原因抛出
解法2：手动设置TransactionStastus.setRollbackOnly()

3、一个方法在多切面情况下,aop切面顺序导致事务不能正确回滚
原因:事务的切面优先级最低，但如果自定义切面优先级和他一样，则还是自定义切面在内层，这时若自定义切面没有正却抛出异常，自定义的事务切面无法知悉，从而做出一些错误的判断，不能正确回滚异常
解法1：同情况2
解法2：设置切面的执行顺序 @(ordered.LOWEST_PRECEDENCE-1) (不推荐)

![在这里插入图片描述](https://img-blog.csdnimg.cn/737beb00d6f54f23aaeea9f325d7d00b.png?x-oss-process=image/watermark,type_d3F5LXplbmhlaQ,shadow_50,text_Q1NETiBA5LiA55Sf5Lik5qyi,size_16,color_FFFFFF,t_70,g_se,x_16


!](https://img-blog.csdnimg.cn/5b7fb14b094b4218b95d0b668bd0bd5b.png?x-oss-process=image/watermark,type_d3F5LXplbmhlaQ,shadow_50,text_Q1NETiBA5LiA55Sf5Lik5qyi,size_16,color_FFFFFF,t_70,g_se,x_16)

4、非public方法导致事务失效
原因：Spring会创建代理Bean(Spring为方法创建代理、添加事务通知、前提条件都是该方法是public的)
解法：改为public

5、父子容器导致的事务失效
原因：子容器扫描范围过大，吧未加事务配置的serviceBean扫描进来
解法1：各扫描各的，不要图简便
解法2：不要用父子容器,所以的Bean放在同一容器（springBoot就一个容器,不会出现这种情况）

6、调用本类方法导致事务的传播行为失效（在一个Service内部，事务方法之间的嵌套调用，普通方法和事务方法之间的嵌套调用，都不会开启新的事务，只要不是用的代理对象proxy的，被调用的目标方法都不会开启事务，目标方法里面报错也不会回滚）

原因：spring 在扫描bean的时候会扫描方法上是否包含@Transactional注解，如果包含，spring会为这个bean动态地生成一个子类（即代理类，proxy），代理类是继承原来那个bean的。此时，当这个有注解的方法被调用的时候，实际上是由代理类来调用的，代理类在调用之前就会启动transaction。然而，如果这个有注解的方法是被同一个类中的其他方法调用的，那么该方法的调用并没有通过代理类，而是直接通过原来的那个bean，所以就不会启动transaction，我们看到的现象就是@Transactional注解无效。

解法1：注入本类代理对象，使用代理对象来调用（spring中通过三级缓存解决了循环依赖问题）
解法2：通过容器上下文方式获取代理对象 (Service6) AopContext.currentProxy()
容器获取前提：设置@EnableAspectJAutoProxy(exposeProxy=true)表示通过aop框架暴露该代理对象，aopContext能够访问.

7、多线程或多请求操作同一个（一行）数据的情况

@Transaction没有保证select语句的原子行为
原因：事务的原子性仅涵盖insert、update、delete、select…for update语句，select方法并不阻塞
理解：数据库的insert、update、delete、select…for update操作默认实现了隐性事务（行锁也叫互斥锁），select语句并没有实现
@Transaction方法导致synchronized失效
原因：synchronized保证的仅是目标方法的原子性,环绕目标方法的还有commit等操作，它们并未处于sync块内
解法1:使用select…for update 的互斥锁机制（数据层面）
解法2：在方法最外层调用加锁（代码控制）

二、spring中循环依赖及解决方案

1、循环依赖–单例对象set循环依赖

一级缓存

能够保证bean在容器中只存在一份（单例），但解决不了循环依赖的问题

一级缓存中循环依赖问题产生

二级缓存

二级缓存能够解决循环依赖问题，但如果原始bean在生成代理bean的过程中，使用了切面比如@Transaction，
对原始bean做了增强，此时注入的bean是原始bean，并不是代理之后的bean，因此会丢失增强的功能
（这里和spring中事务，调用本类方法导致事务的传播行为失效 大同小异）

二级缓存出现问题

三级缓存

spring用三级缓存解决了set循环依赖的问题，提前创建代理对象保留了bean在代理之后所增强的功能

2、循环依赖–构造方法循环依赖

spring的三级缓存并不能解决构造的循环依赖，因为set循环依赖是：最开始的原始对象A，B是能够被创建，构造方法并不能创建最原始的A,B对象（A的实例都创建不成功）。

解决思路：
方案一：

方案二：

方案三：