（例如文件未找到这种需要去声明异常或者需要try。。catch处理的）
原因：spring只对Error和RuntimeException这两个类及其子类才会进行回滚操作，如果抛出的是检查异常并不会进行回滚。
解决：在注解上表明回滚的异常
抛出检查异常导致事务不能正确回滚
原因: Spring 默认只会回滚非检查异常
解法:配置rollbackFor属性
声明式事务的实现原理：
声明式事务再容器中拿得的bean并不是我们的原始目标对象，而是代理对象，代理对象在调用相关方法的时候去调用事务通知，也就是帮我们加事务的控制（是提交还是回滚），在事务通知内部才会去调用原始的目标对象，事务通知是一个环绕通知，环绕通知内部再调你的原始目标对象的方法，所以它这个是在最里面被调用的，如果最里层方法把异常捕捉住了，那外层的事务通知，他不知道这个方法是有异常的，它就提交了事务。
异常必须抛出去，对于外层的调用者才知道。不把异常抛出去，外层的事务不知道，所以会提交事务。
解决：
1.将异常抛出去
2.告诉外层调用者回滚事务
业务方法内自己try-catch异常导致事务不能正确回滚
3、切面顺序原因:事务通知只有捉到了目标抛出的异常，才能进行后续的回滚处理，如果目标自己处理掉异常，事务通知无法知悉
解法1:异常原样抛出
解法2:手动设置TransactionStatus.setRollbackonly()
切面类：
要织入的方法：
执行顺序：
先是最外层事务切面（环绕通知）， 中间一层是自定义的切面，最里层是目标方法。
事务失效分析：
目标方法抛出异常，这个异常先抛给中间一层的自定义的切面。中间自定义的切面中try…catch了，没有将异常抛给外层切面事务。
解决方法和上面的2是一样的。要么将异常抛出，要么调用setRollbackonly()方法。
解决方法三：交换事务切面和自定义切面的顺序，使用order，数字越小的优先级越高。（浓缩的都是精华）
spring的是事务切面的order为最大的整数值，也就是说优先级最低。
我们的目标方法抛出异常后，被里层的事务切面拿到，进行事务回滚。
总结：我们处理异常的时候尽量使用抛出异常的方式，让spring事务进行回滚。
- aop 切面顺序导致导致事务不能正确回滚
4、非public方法原因:事务切面优先级最低,但如果自定义的切面优先级和他一样，则还是自定义切面在内层,这时若自定义切面没有正确抛出异常…
解决同2
@Transactional注解必须加在公共方法上，否则形同虚设
总结 5、父子容器添加controller方法调用service
对于controller和service我们可以将它们配置在同一个容器当中，也可以将它们配置在父子容器中。
将service、mapper、数据源放在父容器当中，controller放在子容器当中。
父子容器设置完了有什么用？
子容器找某个bean的时候，比如子容器要用到service，如果子容器里面没有这个service，那它就回到父容器里面去找，完成依赖注入。
发现在controller调service方法的时候根本就没有加上事务。
原因：子容器里面包扫描的范围太大了，将service也扫描进来了，但是我们子容器里没有配置声明式事务。这个时候controller注入的是子容器里面的service。
只有在父容器里面才配置了@EnableTransactionManagement。
解决：
6、本类方法调用（传播行为失效）不要让子容器controller扫描到他不该扫描到的包，只扫描controller所在的包即可。
传播行为：
REQUIRED：如果之前没有事务，那它就会创建新的事务。如果有了事务，那就加入已有的事务。REQUIRES_NEW:不管之前有没有事务，都会创建一个新的事务。
两个方法相互调用，bar方法会创建一个新的事务，所以应该会有两个事务。
发现只有一个事务，两个方法在一个事务中。
问题出在事务的代理上。因为事务的增强功能只有通过代理去调用这个方法，才会代理调用我们的事务通知，事务通知再调目标，才具备事务的增强。
但是在foo方法的内部，需要间接调用bar方法的时候。bar（）方法不是通过代理调用的，不会进行功能的增强。
解决：
让bar（）方法调用的时候也要通过代理对象去调用才可以。
1、自身注入自身（循环依赖）
2、通过AopContext（aop上下文）得到当前代理对象(要设置expose=true)
上面两种解决方法都是获取代理对象实现功能增强。
7、原子性失效多线程下这段转帐代码是有问题的。
使用CountDownLatch进行多线程测试
先让主线程等待（latch.await()），当线程1和2都执行完了，主线程恢复向下运行。
发现一号账户转成了负数，出现了问题。
多线程下会出现指令交错，
会想到在方法上加synchronized加锁，但还是有问题。
即在方法中的操作执行完了（三条数据库操作），这个时候synchronized就会把锁释放，但是这个时候事务还没提交，此刻另外一个线程抢到了锁，在对其进行操作，就会出现问题。
解决：
1、在调用转帐方法的时候加锁，扩大锁的范围
它就不仅包括目标方法的调用，还有代理方法，以及中间事务通知包括目标方法。他们的调用都是原子的。
锁的位置不能加在目标方法上，要加就要加在代理方法的调用上
2、利用数据库加锁和事务配合使用
select不会阻塞，但是可以修改让其加锁阻塞
如果你把synchronized加载目标方法上，并不能保证原子性，因为目标方法里仅包含了sql语句的操作，最后的提交操作是在通知里完成的。加在目标方法上的synchronized并不能将通知上的提交操作也保护起来
可以修改让其加锁阻塞
[外链图片转存中…(img-3W6Re8cG-1648384749282)]
[外链图片转存中…(img-n97p7q61-1648384749283)]
如果你把synchronized加载目标方法上，并不能保证原子性，因为目标方法里仅包含了sql语句的操作，最后的提交操作是在通知里完成的。加在目标方法上的synchronized并不能将通知上的提交操作也保护起来
