1、详细介绍
事务管理是应用系统开发中必不可少的一部分。Spring 为事务管理提供了丰富的功能支持。Spring 事务管理分为编程式和声明式的两种方式。
编程式事务指的是通过编码方式实现事务；声明式事务基于 AOP,将具体业务逻辑与事务处理解耦。
声明式事务管理使业务代码逻辑不受污染, 因此在实际使用中声明式事务用的比较多。

声明式事务有两种方式，一种是在配置文件（xml）中做相关的事务规则声明，另一种是基于@Transactional注解的方式。

@Transactional可以作用于接口、接口方法、类以及类方法上。当作用于类上时，该类的所有public方法将都具有该类型的事务属性，同时，我们也可以在方法级别使用该标注来覆盖类级别的定义。

虽然@Transactional注解可以作用于接口、接口方法、类以及类方法上，但是Spring建议不要在接口或者接口方法上使用该注解，因为这只有在使用基于接口的代理时它才会生效。

另外，@Transactional注解应该只被应用到public方法上，这是由Spring AOP的本质决定的。如果你在protected、private或者默认可见性的方法上使用@Transactional注解，这将被忽略，也不会抛出任何异常。

默认情况下，只有来自外部的方法调用才会被AOP代理捕获，也就是，类内部方法调用本类内部的其他方法并不会引起事务行为，即使被调用方法使用@Transactional注解进行修饰。

2、使用方法
注：SpringBoot项目会自动配置一个DataSourceTransactionManager，所以我们只需在方法（或者类）加上@Transactional注解，就自动纳入Spring的事务管理了。如下在方法加上 @Transactional 注解：

@Transactional(readOnly = false,isolation = Isolation.READ_COMMITTED,rollbackFor = Exception.class)public RestResult check(OrdHead entity){entity = this.getById(entity.getId());List<OrdBody> ordBodyList = ordBodyService.getListBySearch(new OrdBody() , "bill_num" , entity.getBillNum());return null;}

3、Spring事务的默认回滚机制
Spring的事务管理默认是针对unchecked exception回滚，也就是默认对Error异常和RuntimeException异常以及其子类进行事务回滚，且必须抛出异常。若使用try-catch对其异常捕获则不会进行回滚！（Error异常和RuntimeException异常抛出时不需要方法调用throws或try-catch语句）。而checked exception** 则必须用try语句块进行处理或者把异常交给上级方法处理总之就是必须写代码处理它，所以必须在service捕获异常，然后再次抛出，这样事务方才起效。

4、Java 异常介绍
Java标准库内建了一些通用的异常，这些类以Throwable为顶层父类。Throwable又派生出Error类和Exception类。错误：Error类以及他的子类的实例，代表了JVM本身的错误。错误不能被程序员通过代码处理，Error很少出现。因此，程序员应该关注Exception为父类的分支下的各种异常类。异常：Exception以及他的子类，代表程序运行时发送的各种不期望发生的事件。可以被Java异常处理机制使用，是异常处理的核心。

注意：上图中有个错误 - ClassNotFoundException不属于运行时异常！总体上我们根据Javac对异常的处理要求，将异常类分为2类。非检查异常（unckecked exception）：Error和RuntimeException以及他们的子类。javac在编译时，不会提示和发现这样的异常，不要求在程序处理这些异常。所以如果愿意，我们可以编写代码处理（使用try…catch…finally）这样的异常，也可以不处理。对于这些异常，我们应该修正代码，而不是去通过异常处理器处理。这样的异常发生的原因多半是代码写的有问题。

如除0错误ArithmeticException，错误的强制类型转换错误ClassCastException，数组索引越界ArrayIndexOutOfBoundsException，使用了空对象NullPointerException等等。检查异常（checked exception）：除了Error 和 RuntimeException的其它异常。javac强制要求程序员为这样的异常做预备处理工作（使用try…catch…finally或者throws）。在方法中要么用try-catch语句捕获它并处理，要么用throws子句声明抛出它，否则编译不会通过。这样的异常一般是由程序的运行环境导致的。因为程序可能被运行在各种未知的环境下，而程序员无法干预用户如何使用他编写的程序，于是程序员就应该为这样的异常时刻准备着。
如SQLException , IOException,ClassNotFoundException 等。需要明确的是：检查和非检查是对于javac来说的，这样就很好理解和区分了

 

5、@Transactional注解属性介绍
value和transactionManager属性,它们两个是一样的意思。当配置了多个事务管理器时，可以使用该属性指定选择哪个事务管理器。
propagation属性,事务的传播行为，默认值为Propagation.REQUIRED。

可选的值有：
Propagation.REQUIRED 如果当前存在事务，则加入该事务，如果当前不存在事务，则创建一个新的事务。如a方法和b方法都添加了注解，使用默认传播模式，则a方法内部调用b方法，会把两个方法的事务合并为一个事务。这里又会存在问题，如果b方法内部抛了异常，而a方法catch了b方法的异常，那这个事务还能正常运行吗？答案是不行！会抛出异常：
org.springframework.transaction.UnexpectedRollbackException: Transaction rolled back because it has been marked as rollback-only，因为当ServiceB中抛出了一个异常以后，ServiceB会把当前的transaction标记为需要rollback。但是ServiceA中捕获了这个异常，并进行了处理，认为当前transaction应该正常commit。此时就出现了前后不一致，也就是因为这样，抛出了前面的UnexpectedRollbackException。Propagation.SUPPORTS
如果当前存在事务，则加入该事务；如果当前不存在事务，则以非事务的方式继续运行。

Propagation.MANDATORY 如果当前存在事务，则加入该事务；如果当前不存在事务，则抛出异常。

Propagation.REQUIRES_NEW 重新创建一个新的事务，如果当前存在事务，暂停当前的事务。这个属性可以实现：
类A中的a方法加上默认注解@Transactional(propagation = Propagation.REQUIRED)，类B中的b方法加上注解@Transactional(propagation = Propagation.REQUIRES_NEW)，然后在a方法中调用b方法操作数据库，再在a方法最后抛出异常，会发现a方法中的b方法对数据库的操作没有回滚，因为Propagation.REQUIRES_NEW会暂停a方法的事务。

Propagation.NOT_SUPPORTED 以非事务的方式运行，如果当前存在事务，暂停当前的事务。

Propagation.NEVER 以非事务的方式运行，如果当前存在事务，则抛出异常。

Propagation.NESTED 和 Propagation.REQUIRED 效果一样。

isolation属性 事务的隔离级别，默认值为 Isolation.DEFAULT。

可选的值有： 

DEFAULT ：这是默认值，表示使用底层数据库的默认隔离级别。对大部分数据库而言，通常这值就是： READ_COMMITTED 。 
READ_UNCOMMITTED ：该隔离级别表示一个事务可以读取另一个事务修改但还没有提交的数据。该级别不能防止脏读和不可重复读，因此很少使用该隔离级别。 
READ_COMMITTED ：该隔离级别表示一个事务只能读取另一个事务已经提交的数据。该级别可以防止脏读，这也是大多数情况下的推荐值。 
REPEATABLE_READ ：该隔离级别表示一个事务在整个过程中可以多次重复执行某个查询，并且每次返回的记录都相同。即使在多次查询之间有新增的数据满足该查询，这些新增的记录也会被忽略。该级别可以防止脏读和不可重复读。 
SERIALIZABLE ：所有的事务依次逐个执行，这样事务之间就完全不可能产生干扰，也就是说，该级别可以防止脏读、不可重复读以及幻读。但是这将严重影响程序的性能。通常情况下也不会用到该级别。

timeout属性：事务的超时时间，默认值为-1。如果超过该时间限制但事务还没有完成，则自动回滚事务。

readOnly属性：指定事务是否为只读事务，默认值为 false；为了忽略那些不需要事务的方法，比如读取数据，可以设置 read-only 为 true。

rollbackFor属性：用于指定能够触发事务回滚的异常类型，可以指定多个异常类型。

noRollbackFor属性：抛出指定的异常类型，不回滚事务，也可以指定多个异常类型。

6、@Transactional事务几点注意,这里面有几点需要大家留意：
        A. 一个功能是否要事务，必须纳入设计、编码考虑。不能仅仅完成了基本功能就ok。
        B. 如果加了事务，必须做好开发环境测试（测试环境也尽量触发异常、测试回滚），确保事务生效。
        C. 以下列了事务使用过程的注意事项，请大家留意。
                1）不要在接口上声明@Transactional，而要在具体类的方法上使用@Transactional注解，否则注解可能无效。
                2）不要图省事，将@Transactional放置在类级的声明中，放在类声明，会使得所有方法都有事务。故@Transactional应该放在方法级别，不需要使用事务的方法，就不要放置事务，比如查询方法。否则对性能是有影响的。
                3）使用了@Transactional的方法，对同一个类里面的方法调用，@Transactional无效。比如有一个类Test，它的一个方法A，A再调用Test本类的方法B（不管B是否public还是private），但A没有声明注解事务，而B有。则外部调用A之后，B的事务是不会起作用的。（经常在这里出错）
                4）使用了@Transactional的方法，只能是public，@Transactional注解的方法都是被外部其他类调用才有效，故只能是public。道理和上面的有关联。故在protected、private或者package-visible的方法上使用 @Transactional 注解，它也不会报错，但事务无效。
                5）spring的事务在抛异常的时候会回滚，如果是catch捕获了，事务无效。可以在catch里面加throw new RuntimeException();
                6）最后有个关键的一点：和锁同时使用需要注意：由于Spring事务是通过AOP实现的，所以在方法执行之前会有开启事务，之后会有提交事务逻辑。而synchronized代码块执行是在事务之内执行的，可以推断在synchronized代码块执行完时，事务还未提交，其他线程进入synchronized代码块后，读取的数据不是最新的。
所以必须使synchronized锁的范围大于事务控制的范围，把synchronized加到Controller层或者大于事务边界的调用层！

参考链接：

SpringBoot使用@Transactional注解配置事务 - 宋晓华 - 博客园 (cnblogs.com)

SpringBoot设置事务隔离等级 - 那些年的代码 - 博客园 (cnblogs.com)