你了解spring事务的传播特性和隔离级别吗?

这块了解一些，首先spring一共定义了七种事务传播属性

1.propagation_required(支持当前事务，如果当前没有事务，就新建一个事务。这是最常见的选择)
2.propagation_supports(支持当前事务，如果当前没有事务，就以非事务方式执行)
3.propagation_mandatory(支持当前事务，如果当前没有事务，就抛出异常)
4.propagation_requires_new(新建事务，如果当前存在事务，把当前事务挂起)
5.propagation_not_supported(以非事务方式执行操作，如果当前存在事务，就把当前事务挂起)
6.propagation_never(以非事务方式执行，如果当前存在事务，则抛出异常)
7.propagation_nested(如果当前存在事务，则在嵌套事务内执行。如果当前没有事务，则进行与PROPAGATION_REQUIRED类似的操作)】

但是在我个人平时的开发中接触比较多的就是那个propagation_required,这种事务传播特性可支持当前事务，如果当前没有事务则会新创建一个事务，打个比方说：有两个方法methodA和methodB，如果这两个方法都配置了该事务，当methodA方法内调用methodB方法时methodB是支持methodA事务的,同时如果methodA没有事务,methodB有事务,那么就会新建一个事务。同时spring还定义了如propagation_supports、propagetion_never、propagation_requires_new等其他事物传播特性。

事物隔级别这块，spring共支持5种事物隔离级别，分别是
默认隔离级别（Default:使用数据库设置的隔离级别(默认),由DBA默认的设置来觉得隔离级别）
读未提交数据（read uncommited读未提交数据：所有的事务都可以“看到”未提交事务的执行结果；会导致脏读、不可重复读和幻读的问题的出现）
读已提交数据（read commited读已提交数据：一个事务在开始时，只能"看见"已提交事务所做的改变；Oracle和sql server默认的级别，可以避免脏读，但不可重复读和幻读问题仍然会出现）
可重复读（Repeatable read可重读：确保同一事务的多个实例在并发读取数据时，会看到同样的行，事务在读取某数据的瞬间（就是开始读取的瞬间），必须先对其加 行级共享锁，直到事务结束才释放；
事务在更新某数据的瞬间（就是发生更新的瞬间），必须先对其加 行级排他锁，直到事务结束才释放）
可串行化（Serializable可串行化：最高的事务隔离级别，每个读的数据上加上共享锁
事务在读取数据时，必须先对其加 表级共享锁 ，直到事务结束才释放；
事务在更新数据时，必须先对其加 表级排他锁 ，直到事务结束才释放）

这里，不同的隔离级别，会出现不同的影响：

对于读取未提交数据（read uncommited）来说，可能会出现脏读、幻读和不可重复读

打个比方说：事务A执行update操作将字段name的值从小明更改为小黄,但是它没有提交,这时事务B来读数据库,读到的name等于小黄,如果事务A进行了事物回滚,这就对于事物B来说小黄是无效数据，也造成了脏读。

对于读已提交数据（read commited）来说，虽然避免了数据脏读，但是也可能会造成幻读的发生

比如：事务A对user表某一行进行读取操作,读到name=小明,这时事务B执行了update操作将字段name的值从小明更改为小黄,并在事务A未提交前已成功提交事务,此时对于事务A来说name真实的值不再是小明,这样造成了数据幻读。

但是对于可重复读（Repeatable read）来说，在同事务多实例的并发环境下可避免幻读的产生，它是使用锁机制实现的

比如说：在并发环境下，事务A在读取某行数据时,会对这一行加行级共享锁,该锁仅仅对读操作事务共享，这样保证了当其他事务读取到这行记录时数据可达到一致，避免幻读发生, 同时如果事务A对表中某一行数据进行更改操作,那么会对该行添加行级排它锁,这把锁会排斥其他事务对该行的修改操作，做到了数据一致性。

串行化（Serializable）:与可重读的类似,它不是使用行级共享锁或者行级排它锁实现的，而是使用了表级共享锁和表级排它锁，相对可重读的来说，支持的并发效率不高。