Spring事务注解

大家好，欢迎来到IT知识分享网。

​

一、事务特性

@Transactional注解是用于事务控制的，需要知道事务的ACID特征：即原子性（Atomicity，或称不可分割性）、一致性（Consistency）、隔离性（Isolation，又称独立性）、持久性（Durability）。

事务是用来控制数据的ACID特性的，用于保证数据的正确性和完整性。

@Transactional注解有两种使用方式：

（1）标注在类上面：
当作用于类上时，该类的所有public方法将都具有该类型的事务属性，同时，我们也可以在方法级别使用该标注来覆盖类级别的定义。

（2）标注在方法上面：
当作用于方法上时，只有当该方法发生了异常才会进行回滚，其他的方法不受影响。

在项目中使用，@Transactional(rollbackFor=Exception.class)，如果类加了这个注解，那么这个类里面的方法抛出异常，就会回滚，数据库里面的数据也会回滚。在@Transactional注解中如果不配置rollbackFor属性，那么事物只会在遇到RuntimeException的时候才会回滚，加上rollbackFor=Exception.class，可以让事物在遇到非运行时异常时也回滚。

二、事务传播行为与隔离级别

@Transactional(isolation = Isolation.DEFAULT, propagation = Propagation.REQUIRED, rollbackFor = Exception.class) 

（1）事物传播行为介绍:

@Transactional(propagation=Propagation.REQUIRED) ：如果有事务, 那么加入事务, 没有的话新建一个(默认情况下)
@Transactional(propagation=Propagation.NOT_SUPPORTED) ：容器不为这个方法开启事务
@Transactional(propagation=Propagation.REQUIRES_NEW) ：不管是否存在事务，都创建一个新的事务，原来的挂起，新的执行完毕后继续执行老的事务
@Transactional(propagation=Propagation.MANDATORY) ：必须在一个已有的事务中执行，否则抛出异常
@Transactional(propagation=Propagation.NEVER) ：必须在一个没有的事务中执行，否则抛出异常(与Propagation.MANDATORY相反)
@Transactional(propagation=Propagation.SUPPORTS) ：如果其他bean调用这个方法，在其他bean中声明事务那就用事务，如果其他bean没有声明事务，那就不用事务

（2）事物超时设置：

@Transactional(timeout=30) //默认是30秒 

（3）事务隔离级别：

@Transactional(isolation = Isolation.READ_UNCOMMITTED)：读取未提交数据(会出现脏读, 不可重复读) 基本不使用 @Transactional(isolation = Isolation.READ_COMMITTED)：读取已提交数据(会出现不可重复读和幻读) @Transactional(isolation = Isolation.REPEATABLE_READ)：可重复读(会出现幻读) @Transactional(isolation = Isolation.SERIALIZABLE)：串行化 MYSQL: 默认为REPEATABLE_READ级别 SQLSERVER: 默认为READ_COMMITTED 

脏读 :
一个事务读取到另一事务未提交的更新数据。
不可重复读 :
在同一事务中，多次读取同一数据返回的结果有所不同，即后续读取可能读到另一事务已提交的更新数据， 相反， “可重复读”在同一事务中多次读取数据时能够保证所读数据一样，即后续读取不能读到另一事务已提交的更新数据。
幻读 :
一个事务读到另一个事务已提交的insert数据。

三、spring支持编程式事务管理和声明式事务管理两种方式

（1）编程式事务管理使用TransactionTemplate或者直接使用底层的PlatformTransactionManager。对于编程式事务管理，spring推荐使用TransactionTemplate。
（2）声明式事务管理建立在AOP之上的。其本质是对方法前后进行拦截，然后在目标方法开始之前创建或者加入一个事务，在执行完目标方法之后根据执行情况提交或者回滚事务。声明式事务管理也有两种常用的方式：一种是基于tx和aop名字空间的xml配置文件；另一种是基于@Transactional注解。显然基于注解的方式更简单易用，更清爽。
使用注解形式的方式使用事务需要在xml配置文件中配置如下信息

<!-- 服务事务管理 --> <bean id="demoTransactionManager" class="org.springframework.jdbc.datasource.DataSourceTransactionManager"> <property name="dataSource" ref="demoDataSource"/> </bean> <!-- 启用事务注解 --> <tx:annotation-driven transaction-manager="demoTransactionManager"/> 

四、需要注意的几点如下

@Transactional( rollbackFor=Exception.class)， 如果让unchecked异常不回滚： @Transactional(notRollbackFor=RunTimeException.class)。如下代码所示： @Transactional(rollbackFor=Exception.class) //指定回滚,遇到异常Exception时回滚 public void methodName() { 
    　　　throw new Exception("注释"); } @Transactional(noRollbackFor=Exception.class)//指定不回滚,遇到运行期例外(throw new RuntimeException("注释");)会回滚 public ItimDaoImpl getItemDaoImpl() { 
    　　　throw new RuntimeException("注释"); } 

（3）@Transactional 注解应该只被应用到public可见度的方法上。 如果你在 protected、private 或者 package-visible 的方法上使用 @Transactional 注解，它也不会报错， 但是这个被注解的方法将不具有事务功能。
（4）@Transactional 注解可以被应用于接口定义和接口方法、类定义和类的 public 方法上。然而，请注意仅仅 @Transactional 注解的出现不足于开启事务行为，它仅仅是一种元数据，能够被可以识别。上面的例子中，其实正是元素的出现开启了事务行为。也就是说要有具体的bean出现时事务才会起作用。
（5）Spring团队建议在具体的类（或类的方法）上使用@Transactional 注解，而不要使用在类所要实现的任何接口上。你当然可以在接口上使用 @Transactional 注解，但是这将只能当你设置了基于接口的代理时它才生效。因为注解是不能继承的，这就意味着如果你正在使用基于类的代理时，那么事务的设置将不能被基于类的代理所识别。因此，请接受Spring团队的建议，必须接受啊！

五、@Transactional注解所具有的属性

六、事务可能导致锁表

事务有可能导致锁表，从而导致查询操作超时。锁表的原因是多个事务同时操作某一张表。

七、注解失效场景

1、@Transactional 应用在非 public 修饰的方法上
如果Transactional注解应用在非public 修饰的方法上，Transactional将会失效。

之所以会失效是因为在Spring AOP 代理时，如上图所示 TransactionInterceptor （事务拦截器）在目标方法执行前后进行拦截，DynamicAdvisedInterceptor（CglibAopProxy 的内部类）的 intercept 方法或 JdkDynamicAopProxy 的 invoke 方法会间接调用
AbstractFallbackTransactionAttributeSource的
computeTransactionAttribute 方法，获取Transactional 注解的事务配置信息。

protected TransactionAttribute computeTransactionAttribute(Method method, Class<?> targetClass) { 
    // Don't allow no-public methods as required. if (allowPublicMethodsOnly() && !Modifier.isPublic(method.getModifiers())) { 
    return null; } 

此方法会检查目标方法的修饰符是否为 public，不是 public则不会获取@Transactional 的属性配置信息。

注意：protected、private 修饰的方法上使用 @Transactional 注解，虽然事务无效，但不会有任何报错，这是我们很容犯错的一点。

2、@Transactional 注解属性 propagation 设置错误
这种失效是由于配置错误，若是错误的配置以下三种 propagation，事务将不会发生回滚。

TransactionDefinition.PROPAGATION_SUPPORTS：如果当前存在事务，则加入该事务；如果当前没有事务，则以非事务的方式继续运行。
TransactionDefinition.PROPAGATION_NOT_SUPPORTED：以非事务方式运行，如果当前存在事务，则把当前事务挂起。
TransactionDefinition.PROPAGATION_NEVER：以非事务方式运行，如果当前存在事务，则抛出异常。

3、@Transactional 注解属性 rollbackFor 设置错误
rollbackFor 可以指定能够触发事务回滚的异常类型。Spring默认抛出了未检查unchecked异常（继承自 RuntimeException 的异常）或者 Error才回滚事务；其他异常不会触发回滚事务。如果在事务中抛出其他类型的异常，但却期望 Spring 能够回滚事务，就需要指定rollbackFor属性。

// 希望自定义的异常可以进行回滚

@Transactional(propagation= Propagation.REQUIRED,rollbackFor= MyException.class 

若在目标方法中抛出的异常是 rollbackFor 指定的异常的子类，事务同样会回滚。Spring源码如下：

private int getDepth(Class<?> exceptionClass, int depth) { 
    if (exceptionClass.getName().contains(this.exceptionName)) { 
    // Found it! return depth; } // If we've gone as far as we can go and haven't found it... if (exceptionClass == Throwable.class) { 
    return -1; } return getDepth(exceptionClass.getSuperclass(), depth + 1); } 

4、同一个类中方法调用，导致@Transactional失效
开发中避免不了会对同一个类里面的方法调用，比如有一个类Test，它的一个方法A，A再调用本类的方法B（不论方法B是用public还是private修饰），但方法A没有声明注解事务，而B方法有。则外部调用方法A之后，方法B的事务是不会起作用的。这也是经常犯错误的一个地方。

那为啥会出现这种情况？其实这还是由于使用Spring AOP代理造成的，因为只有当事务方法被当前类以外的代码调用时，才会由Spring生成的代理对象来管理。

//@Transactional @GetMapping("/test") private Integer A() throws Exception { 
    CityInfoDict cityInfoDict = new CityInfoDict(); cityInfoDict.setCityName("2"); / * B 插入字段为 3的数据 */ this.insertB(); / * A 插入字段为 2的数据 */ int insert = cityInfoDictMapper.insert(cityInfoDict); return insert; } @Transactional() public Integer insertB() throws Exception { 
    CityInfoDict cityInfoDict = new CityInfoDict(); cityInfoDict.setCityName("3"); cityInfoDict.setParentCityId(3); return cityInfoDictMapper.insert(cityInfoDict); } 

5、异常被你的 catch“吃了”导致@Transactional失效
这种情况是最常见的一种@Transactional注解失效场景，

@Transactional private Integer A() throws Exception { 
    int insert = 0; try { 
    CityInfoDict cityInfoDict = new CityInfoDict(); cityInfoDict.setCityName("2"); cityInfoDict.setParentCityId(2); / * A 插入字段为 2的数据 */ insert = cityInfoDictMapper.insert(cityInfoDict); / * B 插入字段为 3的数据 */ b.insertB(); } catch (Exception e) { 
    e.printStackTrace(); } } ``` 如果B方法内部抛了异常，而A方法此时try catch了B方法的异常，那这个事务还能正常回滚吗？ 答案：不能！ 会抛出异常： ```java org.springframework.transaction.UnexpectedRollbackException: Transaction rolled back because it has been marked as rollback-only 

因为当ServiceB中抛出了一个异常以后，ServiceB标识当前事务需要rollback。但是ServiceA中由于你手动的捕获这个异常并进行处理，ServiceA认为当前事务应该正常commit。此时就出现了前后不一致，也就是因为这样，抛出了前面的

UnexpectedRollbackException异常。

spring的事务是在调用业务方法之前开始的，业务方法执行完毕之后才执行commit or rollback，事务是否执行取决于是否抛出runtime异常。如果抛出runtime exception 并在你的业务方法中没有catch到的话，事务会回滚。

在业务方法中一般不需要catch异常，如果非要catch一定要抛出throw new RuntimeException()，或者注解中指定抛异常类型@Transactional(rollbackFor=Exception.class)，否则会导致事务失效，数据commit造成数据不一致，所以有些时候try catch反倒会画蛇添足。

6、数据库引擎不支持事务
这种情况出现的概率并不高，事务能否生效数据库引擎是否支持事务是关键。常用的MySQL数据库默认使用支持事务的innodb引擎。一旦数据库引擎切换成不支持事务的myisam，那事务就从根本上失效了。

参考链接：
Spring事务注解
注解失效场景

​