一、Transaction:
Spring中提供了很好的事务管理机制--编程式事务和声明式事务。编程式事务管理是侵入性事务管理，使用TransactionTemplate或者PlatformTransactionManager手动管理事务的提交、回滚等操作。其中声明式事务建立在AOP之上，原理是对方法进行拦截，在目标方法执行之前添加事务，目标方法执行后根据执行情况进行事务的提交或回滚。编程式事务是侵入式的，声明式事务是非侵入性的，因此，提倡使用声明式事务。@Transactional注解是实现声明式事务的方式之一。
1.1作用域
@Transaction 可以作用在类、接口、方法上
类上：表示给该类所有的 public 方法添加上 @Transaction 注解
接口上：只有在使用基于接口的代理时它才会生效。像 CGLib 动态代理采用继承的方式将会导致 @Transactional 注解失效。不推荐使用
方法上：事务的作用域就只在该方法上生效，并且如果类及方法上都配置 @Transaction 注解时，方法的注解会覆盖类上的注解
1.2属性
属性说明
1)valuevalue 主要用来指定不同的事务管理器，满足在同一个系统中，存在不同的事务管理器。如果在 Spring 中，配置了多个数据源声明了多个事务管理器，可以通过该参数来进行指定事务管理器。
2)propagation
枚举值含义
3)isolation
4)rollbackFor 和 rollbackForClassNamerollbackFor：通过类进行指定，如@Transactional(rollbackFor = {Exception.class})
rollbackForClassName：通过类名进行指定，如@Transaction(rollbackForClassName = {"java.lang.Exception"})
5)noRollbackFor 和 noRollbackForClassName与4）一致
6)手动回滚TransactionAspectSupport.currentTransactionStatus().setRollbackOnly();
二、总览：
三、失效场景
3.1、代理异常导致
Spring中对注解解析的都是基于代理的，如果目标方法无法被Spring代理到，那么它将无法被Spring进行事务管理。
Spring生成代理的方式有两种：
（1）基于接口的JDK动态代理，要求目标代理类需要实现一个接口才能被代理
（2）基于实现目标类子类的CGLIB代理Spring在2.0之前，目标类如果实现了接口，则使用JDK动态代理方式，否则通过CGLIB子类的方式生成代理。而在2.0版本之后，如果不在配置文件中显示的指定spring.aop.proxy-tartget-class的值，默认情况下生成代理的方式为CGLIB，如下图
3.1.1 将注解标注在接口方法上
@Transactional是支持标注在方法与类上的。一旦标注在接口上，对应接口实现类的代理方式如果是CGLIB，将通过生成子类的方式生成目标类的代理，将无法解析到@Transactional，从而事务失效。
3.1.2 被final、static关键字修饰的类或方法
事务的管理是通过代理执行的方式生效的，如果是方法内部调用，将不会走代理逻辑，也就调用不到了。
3.1.3 类方法内部调用
事务的管理是通过代理执行的方式生效的，如果是方法内部调用，将不会走代理逻辑，也就调用不到。
解决方式：方式1：新建一个Service，将方法迁移过去，使被调用方独立出去。
方式2：在当前类注入自己，调用createUser1时通过注入的userService调用
方式3：通过AopContext.currentProxy()获取代理对象
3.1.4 未被Spring管理
没有被Spring管理成为IOC容器中的一个bean，无法被事务切面代理到。
3.2 框架不支持
3.2.1 非public修饰方法
3.2.2 多线程调用
在多线程/异步线程的使用场景，也会导致事务失效的发生；TransactionAspectSupport.prepareTransactionInfo方法中，能够看到在完成事务的状态配置后会绑定到当前的线程，所以异步线程/多线程的使用会导致事务传播的失效。
3.2.3 数据库本身不支持事务
比如Mysql的Myisam存储引擎是不支持事务的，只有innodb存储引擎才支持。
3.3 配置错误
3.3.1 传播机制配置错误
不支持事务的传播机制为：PROPAGATION_SUPPORTS，PROPAGATION_NOT_SUPPORTED，PROPAGATION_NEVER。
如果配置了以上三种传播方式的话，在发生异常的时候，事务是不会回滚的。
3.3.2 rollbackFor属性设置错误
默认情况下事务仅回滚运行时异常（RuntimeException）和Error，不回滚受检异常（例如IOException）。所以默认配置可以保证RuntimeException错误的回滚，如果想保证非RuntimeException错误的回滚，需要加上rollbackFor = Exception.class参数，或者其他指定的异常类型。
因此如果方法中抛出了IO异常，默认情况下事务也会回滚失败。
我们可以通过指定@Transactional(rollbackFor = Exception.class)的方式进行全异常捕获。
(1)受检异常:在编译的时候，要强制检查的异常，这种异常需要去显示的通过try/catch来进行捕获或者通过throws去抛出去否则程序无法通过编译的;
(2)非受检异常:非受检异常表示编译器可以不需要去强制去检查异常，这种异常不需要去显示去捕获或者抛出
3.4 使用错误
3.4.1 异常被内部catch
默认情况下标注了@Transactional注解的方法的事务传播机制是REQUIRED，它的特性是支持当前事务，也就说加入当前事务。我们在UserService中开始事务，然后再UserService1中抛出异常回滚UserService中的事务，将其标记为只读。
但是在UserSevice中我们捕获了异常，此时UserService上的事务认为正常提交事务。最后在提交时发现事务只读，已经被回滚，则抛出了上述异常。
因此这里如果需要对特定的异常进行捕获处理，记得再次将异常抛出，让最外层的事务感知到。
3.4.2 嵌套事务
嵌套事务失效主要是在两个或者多个事务嵌套在一起时，且内外层对事务rollbackFor参数配置不一致的场景；（1）外层加上了rollbackFor = Exception.class而内层使用默认，无论内层还是外层抛出非RuntimeException错误均能够正常回滚！（2）若内层加上了rollbackFor = Exception.class而外层使用默认，若外层抛出非RuntimeException错误是无法正常的回滚。若内层抛出非RuntimeException错误，则都能正常回滚。主要是因为在使用默认propagation配置时是使用的propagationPropagation.REQUIRED;REQUIRED的意思是说，事务嵌套的时候，如果发现已经有事务存在了，就加入这个事务，而不是新建一个事务，所以根本就不存在两个事务，一直只有一个；当外层报错的时候，此时查看事务，没有增加处理非RuntimeException能力，所以代码走完，貌似“两个事务”，都回滚失败了。当里面报错的时候，事务已经添加上了处理非RuntimeException能力，所以，代码走完就回滚成功了
