干货分享-- Sping并发事务，隔离级别以及传播属性的灵活运用

前言：在现有互联网架构中，经常有高并发，多线程，分布式锁的场景，这个时候对spring事务

掌控就不仅仅只是写一个Transactional默认走天下了，我学习Spring的最好方式是 结合 spring作者的注释，网上博客资源，最终用代码演示，这样 能将枯燥的知识转化成真正的理解，废话不多说，下面进行结算

Transactional注解

一、在java程序中，对事务的控制比较常见一般有两种方式，spring和javax分别都提供了Transactional进行控制；一个是spring 家族提供，

一个是javax基于EJB3提供，对底层内的容器调用是一致的，spring 提供7个事务传播属性（多个NESTED），javax只有六个，不仅如此spring

的Transactional还提供对隔离级别的控制（Isolation的使用）十分强大，个人推 荐使用spring全家桶的使用。

非事务性事务，我的理解就是不执行事务的意思

二、spring Transactional的传播属性；

REQUIRED（默认级别）:支持当前事务，如果不存在，则创建新事务。Support a current transaction, create a new one if none exists.   

MANDATORY  支持当前事务，如果不存在，则抛一个异常 Support a current transaction, throw an exception if none exists.  .   

这个比较有趣了，可写个代码测试一下。 测试结果的就是这个不能直接调，直接调抛异常，调他的必须也有注解

REQUIRES_NEW  创建一个新事务，如果存在一个事务，则暂停当前事务。Create a new transaction, and suspend the current transaction if one exists. 

这个大概的意思就是，每次都用新的事务，默认是每次都先用新建的事务，因此两个事务不能同时DML同一条数据，新事务的失败不会影响旧事务的回滚，在同一线程下旧事务提交一定是在新事务之后的，这个需要配合try catch使用，这样就可以完美的演示效果

不管是否存在事务,都创建一个新的事务,原来的挂起,新的执行完毕,继续执行老的事务，两次提交事务

SUPPORTS  支持当前事务，如果不存在，则执行非事务性事务。Support a current transaction, execute non-transactionally if none exists. .  

官方 解释是 

注意：对于事务同步的事务管理器， 传播支持与根本没有交易略有不同， 因为它定义了同步将应用的事务范围。

因此，相同的资源（JDBC连接、Hibernate会话等） 将在整个指定范围内共享。注意这取决于 事务管理器的实际同步配置。

如果其他bean调用这个方法,在其他bean中声明事务,那就用事务.如果其他bean没有声明事务,那就不用事务。个人认为非常鸡肋，和不写Transation注解是相同的效果

NOT_SUPPORTED  执行非事务性操作，如果存在，则暂停当前事务。Execute non-transactionally, suspend the current transaction if one exists.   

加上这个属性的方法或类永远不执行事务(不常用)

NEVER  执行非事务性操作，如果事务存在，则引发异常。 Execute non-transactionally, throw an exception if a transaction exists. 

看到这里其实可以知道，非事务性事务和事务性事务分别有三个（支持当前事务，抛异常，暂停当前事务） ，这个比not_supported 还过分，不进不用事务，发现有事务直接就抛异常(不常用)

NESTED 如果存在当前事务，则在嵌套事务中执行 Execute within a nested transaction if a current transaction exists

spring的注释里写 嵌套事务的实际创建只对特定事务管理器工作，只能在DataSourceTransactionManager 用于JDBC的驱动工作，然后还加了一句一些JTA提供者也可能支持嵌套事务。

写这么多，不能用么 ，很鸡肋的感觉。能不能有效果，实用说话 

嵌套事务一个非常重要的概念就是内层事务依赖于外层事务。外层事务失败时，会回滚内层事务所做的动作。而内层事务操作失败并不会引起外层事务的回滚。

NESTED  = REQUIRED + REQUIRES_NEW ，既实现了在子事务在父事务之后提交，又实现了子事务回滚不影响父事务；

对嵌套事务有疑问可以看http://www.iteye.com/topic/35907

需要配置才能生效

三、在事务的隔离级别（五大隔离级别）

1.I SOLATION_DEFAULT ：使用后端数据库默认的隔离级别

2. ISOLATION_READ_UNCOMMITTED：读未提交， 最低的隔离级别，允许读取尚未提交的数据变更

3. ISOLATION_READ_COMMITTED0： 允许读取并发事务已经提交的数据

4. ISOLATION_REPEATABLE_READ：可重复读，同一个字段多次读取结果一致

5. ISOLATION_SERIALIZABLE ：串行读，最高隔离机制，完全锁定事务相关表

事务的并发问题

　　1、脏读：事务A读取了事务B更新的数据，然后B回滚操作，那么A读取到的数据是脏数据

　　2、不可重复读：事务 A 多次读取同一数据，事务 B 在事务A多次读取的过程中，对数据作了更新并提交，导致事务A多次读取同一数据时，结果 不一致。

　　3、幻读：系统管理员A将数据库中所有学生的成绩从具体分数改为ABCDE等级，但是系统管理员B就在这个时候插入了一条具体分数的记录，当系统管理员A改结束后发现还有一条记录没有改过来，就好像发生了幻觉一样，这就叫幻读。

mysql

事务隔离级别	脏读	不可重复读	幻读
读未提交（read-uncommitted）	是	是	是
不可重复读（read-committed）	否	是	是
可重复读（repeatable-read）	否	否	是
串行化（serializable）	否	否	否

READ_COMMITTED 图示

：

　　小结：不可重复读的和幻读很容易混淆，不可重复读侧重于 修改 ，幻读侧重于 新增或删除 。解决不可重复读的问题只需 锁住满足条件的行 ，解决幻读需要 锁表

    一般高性能对的mysql隔离级别只在 READ_COMMITTED了，允许并发事务的存在，但只读提交的，配合乐观锁的机制还是可以接受的

四   在实际开发中的运用以及一些问题。

1， Transactional 在同一个A类，A方法调B方法，B方法写Transactional时，Transactional不回滚(不同类之间的调用不存在这个问题)?（不回滚具体原因是什么？是不是这个事务完全没生效？）

经本人亲测，这种写法事务完全没有生效，不仅仅是不能回滚。具体造成的原因应该是 spring aop代理机制 

解决方案1：在A方法 写注解，不要在子方法写注解。（没有真正的解决）

解决方案2：springboot通过 @EnableAspectJAutoProxy(exposeProxy=true)  在通过 AopContext.currentProxy()  调用

在默认情况下，大部分使用spring的事务都是使用代理的模式，代理实现的事务有一定的局限性：仅有在公有方法上标记的 @Transactional有效；仅有外部方法调用过程才会被代理截获，事务才会有效，也就是说，一个方法调用本对象的另一个方法，没有通过代理类，事务也就无法生效。

2， 关于Transactional 回滚方案的解释（If no rules are relevant to the exception, it will be treated like DefaultTransactionAttribute (rolling back on RuntimeException and Error

 but not on checked exceptions)api文档是这么说的，大概的意思就默认对RuntimeException 和 Error进行回滚，checked exceptions不进行回滚

总结： Transactional 在用法上还是很灵活的，不推荐在一个类中反复使用事务（spring的代理机制缺陷），博客内容都经过代码测试，代码希望都自己敲一下