Java——Spring的事务详解

1、Spring支持的事务管理类型，Spring事务实现方式有哪些？

• 编程式事务管理： 这意味你通过编程的方式管理事务，给你带来极大的灵活性，但是难维护。
• 声明式事务管理： 这意味着你可以将业务代码和事务管理分离，你只需用注解和 XML 配置来管理事务。

2、Spring事务的实现方式和实现原理？

答： Spring事务的本质其实就是数据库对事务的支持，没有数据库的事务支持，Spring是无法提供事务功能的。真正的数据库层的事务提交和回滚是通过MYSQL实现的。

3、Spring的事务传播行为？

**答：**事务传播行为（Propagation Behavior）指的就是当一个事务方法被另一个事务方法调用时，这个事务方法应该如何进行。

• PROPAGATION_REQUIRED ： 如果当前没有事务，就创建一个新事务，如果当前存在事务，就加入该事务，该设置是最常用的设置。
• PROPAGATION_SUPPORTS ： 支持当前事务，如果当前存在事务，就加入该事务，如果当前不存在事务，就以非事务执行。
• PROPAGATION_MANDATORY ： 支持当前事务，如果当前存在事务，就加入该事务，如果当前不存在事务，就抛出异常。
• PROPAGATION_REQUIRES_NEW ： 创建新事务，无论当前存不存在事务，都创建新事务。
• PROPAGATION_NOT_SUPPORTED ： 以非事务方式执行操作，如果当前存在事务，就把当前事务挂起。
• PROPAGATION_NEVER ： 以非事务方式执行，如果当前存在事务，则抛出异常。
• PROPAGATION_NESTED ： 如果当前存在事务，则在嵌套事务内执行。如果当前没有事务，则按REQUIRED属性执行。

4、Spring的事务隔离？

答：Spring 有五大隔离级别，默认值为 ISOLATION_DEFAULT（使用数据库的设置），其他四个隔离级别和数据库的隔离级别一致：

• ISOLATION_DEFAULT ：用底层数据库的设置隔离级别，数据库设置的是什么我就用什么；
• ISOLATION_READ_UNCOMMITTED ： 未提交读，最低隔离级别、事务未提交前，就可被其他事务读取（会出现幻读、脏读、不可重复读）；
• ISOLATION_READ_COMMITTED ： 提交读，一个事务提交后才能被其他事务读取到（会造成幻读、不可重复读），SQL Server 的默认级别；
• ISOLATION_REPEATABLE_READ ： 可重复读，保证多次读取同一个数据时，其值都和事务开始时候的内容是一致，禁止读取到别的事务未提交的数据（会造成幻读），MySQL 的默认级别；
• ISOLATION_SERIALIZABLE ：串行化，代价最高最可靠的隔离级别，该隔离级别能防止脏读、不可重复读、幻读。

5、脏读、不可重复读和幻读？

• 脏读 ： 表示一个事务能够读取另一个事务中还未提交的数据。比如，某个事务尝试插入记录 A，此时该事务还未提交，然后另一个事务尝试读取到了记录A。
• 不可重复读 ： 是指在一个事务内，多次读同一范围内的数据，获得的结果不一样。
• 幻读 ： 指同一个事务内多次查询返回的结果集不一样。比如同一个事务 A第一次查询时候有 n 条记录，但是第二次同等条件下查询却有 n+1 条记录，这就好像产生了幻觉。发生幻读的原因也是另外一个事务新增或者删除或者修改了第一个事务结果集里面的数据，同一个记录的数据内容被修改了，所有数据行的记录就变多或者变少了。

6、Spring框架的事务管理有哪些优点？

• 为不同的事务提供API 如JTA，JDBC，Hibernate，JPA 和JDO，提供一个不变的编程模式。
• 为编程式事务管理提供了一套**简单的****API**而不是一些复杂的事务API。
• 支持声明式事务管理。
• 和Spring各种数据访问抽象层很好得集成。

7、你更倾向用那种事务管理类型？

答： 大多数Spring框架的用户选择声明式事务管理，因为它对应用代码的影响最小，因此更符合一个无侵入的轻量级容器的思想。声明式事务管理要优于编程式事务管理，虽然比编程式事务管理（这种方式允许你通过代码控制事务）少了一点灵活性。唯一不足地方是，最细粒度只能作用到方法级别，无法做到像编程式事务那样可以作用到代码块级别。

8、事务失效的原因

• Spring的事务注解@Transactional只能放在 public 修饰的方法上 才起作用，如果放在其他非public（private，protected）方法上，虽然不报错，但是事务不起作用；

• 如果采用Spring + Spring MVC，则context:component-scan重复扫描问题可能会引起事务失败。如果Spring和 mvc 的配置文件中都扫描了 service 层，那么事务就会失效；

  答： 因为按照Spring配置文件的加载顺序来讲，先加载 Spring MVC 配置文件，再加载Spring配置文件，我们的事物一般都在Spring配置文件中进行配置，如果此时在加载Spring MVC配置文件的时候，把service也给注册了，但是此时事物还没加载，也就导致后面的事物无法成功注入到service中。所以把对service的扫描放在Spring配置文件中或是其他配置文件中。

• 如使用mysql且引擎是MyISAM，则事务会不起作用，原因是MyISAM不支持事务，可以改成InnoDB引擎；

• @Transactional 注解开启配置，必须放到listener里加载，如果放到DispatcherServlet的配置里，事务也是不起作用的。如果Spring和Spring MVC的配置文件中都扫描了service层，那么事务就会失效。

  答： 因为按照Spring配置文件的加载顺序来讲，先加载Spring MVC配置文件，再加载Spring配置文件，我们的事物一般都在Spring配置文件中进行配置，如果此时在加载Spring MVC配置文件的时候，把service也给注册了，但是此时事物还没加载，也就导致后面的事物无法成功注入到service中。所以把对service的扫描放在Spring配置文件中或是其他配置文件中。

• Spring团队建议在具体的类（或类的方法）上使用 @Transactional 注解，而不要使用在类所要实现的任何接口上。在接口上使用 @Transactional 注解，只能当你设置了基于接口的代理时它才生效。因为注解是 不能继承 的，这就意味着如果正在使用基于类的代理时，那么事务的设置将不能被基于类的代理所识别，而且对象也将不会被事务代理所包装。

• 在业务代码中如果抛出RuntimeException异常，事务回滚；但是抛出Exception，事务不回滚；

• 如果在加有事务的方法内，使用了try...catch..语句块对异常进行了捕获，而catch语句块没有throw new RuntimeExecption异常，事务也不会回滚。

• 在类A里面有方法a 和方法b， 然后方法b上面用@Transactional加了方法级别的事务，在方法a里面 调用了方法b， 方法b里面的事务不会生效。原因是在同一个类之中，方法互相调用，切面无效，而不仅仅是事务。这里事务之所以无效，是因为**Spring的事务是通过aop**实现的。