java事务讲解（详解篇）

本篇博客将各位介绍事务的相关内容，也算是对事物的大部分知识点进行的一个总结，接下来就跟着我一起来学习学习吧~

实现事务

实现事务的方式大类共有两大类，一种是编程式事务，另一种是声明式事务。

编程式事务的好处在于他的最小事务粒度可以达到某个代码块上，且可以根据具体的业务逻辑进行调整；但是坏处在于事务的代码实现和业务逻辑混合在一块，这样在管理业务代码和事务代码上就有了很强的耦合性，不方便管理。

声明式事务好处在于主要是通过aop的方式实现的，在方法上加上注解就可以在方法开始之前开启事务，在方法结束后选择提交事务或者是回滚事务，这样将业务逻辑和事务代码相隔开来更容易管理，实现了非侵入式管理；但是缺点也显而易见，那就是事务的最小粒度为一个方法，无法做到一个代码块上。

那接下来就看看这两类实现事务的方式是如何实现的吧~

编程式事务

这类实现事务的方式主要是通过两种方式实现的，一种是通过PlatformTransactionManager，另一种是通过TransactionTemplate，我们先来看代码：

@Service
public class userService {@Autowiredprivate PlatformTransactionManager platformTransactionManager;@Autowiredprivate TransactionTemplate transactionTemplate;public void usePlatfofrmTransaction() {
//        定义默认的事务属性DefaultTransactionDefinition transactionDefinition = new DefaultTransactionDefinition();TransactionStatus status = platformTransactionManager.getTransaction(transactionDefinition);try {//业务逻辑
//            ....platformTransactionManager.commit(status);} catch (Exception e) {platformTransactionManager.rollback(status);e.printStackTrace();}}public void useTransactionTemplate() {transactionTemplate.execute(new TransactionCallbackWithoutResult() {@Overrideprotected void doInTransactionWithoutResult(TransactionStatus status) {try {//业务逻辑}catch (Exception e){status.setRollbackOnly();e.printStackTrace();}}});}
}

这两种都可以实现事务，但是各有千秋，比较推荐使用TransactionTemplate这种来实现。

对于这种有两个内部类实现：

第一种无返回值，第二种有返回值，根据具体业务代码进行选择。

声明式事务

这类事务实现方式主要就是通过@Transaction注解来实现的，我们又知道注解大部分有事通过aop的方式进行实现的，所以我们就可以在aop中来定义我们具体的事务处理。

因为这个使我们经常处理事务的方式，所以我们这里再来说一下事务的ACID性质，以及spring事务是如何进行处理的。

首先，这里还是简单说一下什么是事务的ACID性质：

原子性（Atomicity）：事务是一个原子操作，由一系列动作组成。事务的原子性确保动作要么全部完成，要么完全不起作用；
一致性（Consistency）：一旦事务完成（不管是成功还是失败），系统必须确保它所建模的业务处于一致的状态，而不会是部分完成部分失败。在现实中的数据不应该被破坏；
隔离性（Isolation）：可能有许多事务会同时处理相同的数据，因此每个事务都应该与其他事务隔离开来，防止数据损坏；
持久性（Durability）：一旦事务完成，无论发生什么系统错误，它的结果都不应该受到影响，这样就能从任何系统崩溃中恢复过来。通常情况下，事务的结果被写到持久化存储器中；

一致性

对于一致性的处理，我们通常采用事务进行解决，这里就要说到事务的7个传播机制了，这里先一一列出，然后我们具体来看区别：

Propagation.REQUIRED：默认的事务传播级别，它表示如果当前存在事务，则加入该事务；如果当前没有事务，则创建一个新的事务。
Propagation.SUPPORTS：如果当前存在事务，则加入该事务；如果当前没有事务，则以非事务的方式继续运行。
Propagation.MANDATORY：（mandatory：强制性）如果当前存在事务，则加入该事务；如果当前没有事务，则抛出异常。
Propagation.REQUIRES_NEW：表示创建一个新的事务，如果当前存在事务，则把当前事务挂起。也就是说不管外部方法是否开启事务，Propagation.REQUIRES_NEW 修饰的内部方法会新开启自己的事务，且开启的事务相互独立，互不干扰。
Propagation.NOT_SUPPORTED：以非事务方式运行，如果当前存在事务，则把当前事务挂起。
Propagation.NEVER：以非事务方式运行，如果当前存在事务，则抛出异常。
Propagation.NESTED：如果当前存在事务，则创建一个事务作为当前事务的嵌套事务来运行；如果当前没有事务，则该取值等价于 PROPAGATION_REQUIRED。

这里先写两个service，由于我是在test环境下测试的事务，所以就算事务成功也不会提交到数据库中，会自动进行回滚，所以要想真的修改到数据库，可以显示调用Rollback（false）就可以了，但是如果是在正常代码中的话就不用了。

Propagation.REQUIRED

这种传播机制就是当两个方法都存在事务的话，在一个方法中调用另一个方法如果成功就会更新到数据库，如果其中一个出现问题，就不会更新到数据库，而是进行回滚。这也是事务默认的传播机制。

1、但是如果有一种情况，当userTransaction没有事务，在testTransaction中调用，想想这个时候会出现什么？

这种情况下userTransaction会加入到testTransaction的事务当中，如果其中一个出现回滚，那最后就不会提交到数据库中。

2、再想想，如果在userTransaction中调用testTransaction，会出现什么情况？

这个时候如果是testTransaction会相对于userTransaction创建一个新事务，此时testTransaction的事务会完全独立于userTransaction，当testTransaction回滚时，userTransaction还是会正常提交到数据库中。

根据以上罗列出的三个不同的情景，我们可以来看一下这7中传播机制在三个场景下分别会怎么进行处理：

场景分析

1. 方法A有事务，方法B没有事务

在这种情况下，方法A开启了事务，而方法B没有事务注解，因此它的事务行为完全取决于方法A的传播机制。

1.1 Propagation.REQUIRED

调用流程：方法A有事务，方法B没有事务。
行为：方法B会加入方法A的事务。即使方法B没有事务注解，它仍然会在方法A的事务中运行。
回滚：如果方法A抛出异常，整个事务（包括方法B的操作）都会回滚。

1.2 Propagation.REQUIRES_NEW

调用流程：方法A有事务，方法B没有事务。
行为：当方法A调用方法B时，方法B会开启一个新的事务，并且方法A的事务会被挂起。方法A和方法B的事务相互独立。
回滚：方法A的异常不会影响方法B的事务，反之亦然。方法B的事务会在方法B执行完后提交，而方法A的事务会在方法A执行完后提交或回滚。

1.3 Propagation.SUPPORTS

调用流程：方法A有事务，方法B没有事务。
行为：方法B会加入方法A的事务（因为方法A有事务）。因此，方法B的操作在方法A的事务中运行。
回滚：方法A回滚时，方法B的操作也会回滚。

1.4 Propagation.NOT_SUPPORTED

调用流程：方法A有事务，方法B没有事务。
行为：当方法A调用方法B时，方法B会挂起方法A的事务，在无事务的上下文中执行。方法B的操作不会受到任何事务的影响。
回滚：方法A回滚时，不会影响方法B的操作，因为方法B没有在事务中运行。

1.5 Propagation.MANDATORY

调用流程：方法A有事务，方法B没有事务。
行为：方法B要求在事务中运行，因此它会加入方法A的事务。如果方法A没有事务，方法B会抛出异常。
回滚：方法A回滚时，方法B的操作也会回滚。

1.6 Propagation.NEVER

调用流程：方法A有事务，方法B没有事务。
行为：方法B不允许在事务中运行，但方法A有事务，因此当方法A调用方法B时，会抛出异常，因为方法B拒绝在事务环境下运行。
回滚：方法B不会执行，直接抛出异常。

1.7 Propagation.NESTED

调用流程：方法A有事务，方法B没有事务。
行为：方法B会在方法A的事务内启动一个嵌套事务。嵌套事务允许方法B的部分事务可以独立提交或回滚，而不影响方法A的事务。
回滚：如果方法A回滚，嵌套事务也会回滚；但是如果方法A不回滚，方法B可以单独回滚自己的嵌套事务。

-------------------------------------------------------------------------------

2. 方法A没有事务，方法B有事务

在这种情况下，方法A没有事务，方法B有事务，因此传播机制决定方法B是否创建或加入现有事务。

2.1 Propagation.REQUIRED

调用流程：方法A没有事务，方法B有事务。
行为：方法B会开启一个新的事务，因为方法A没有事务。
回滚：方法B的事务完全独立于方法A的调用环境，异常回滚仅限于方法B的事务。

2.2 Propagation.REQUIRES_NEW

调用流程：方法A没有事务，方法B有事务。
行为：方法B会强制创建一个新的事务，与方法A无关。
回滚：方法B的事务独立，方法A无事务，异常回滚仅限于方法B。

2.3 Propagation.SUPPORTS

调用流程：方法A没有事务，方法B有事务。
行为：方法B在无事务的上下文中运行，因为方法A没有事务。因此，方法B不会开启事务。
回滚：无事务情况下，方法B的操作不受回滚影响。

2.4 Propagation.NOT_SUPPORTED

调用流程：方法A没有事务，方法B有事务。
行为：方法B会在无事务的上下文中执行，因为传播机制要求暂停任何事务。
回滚：方法B没有事务，因此不会回滚。

2.5 Propagation.MANDATORY

调用流程：方法A没有事务，方法B有事务。
行为：方法B要求有事务才能执行，而方法A没有事务，因此会抛出异常。
回滚：方法B不会执行，直接抛出异常。

2.6 Propagation.NEVER

调用流程：方法A没有事务，方法B有事务。
行为：方法B要求无事务才能执行，而方法A没有事务，因此方法B会执行。
回滚：方法B在无事务的上下文中执行，因此不受回滚影响。

2.7 Propagation.NESTED

调用流程：方法A没有事务，方法B有事务。
行为：因为方法A没有事务，所以方法B会启动一个新的事务，类似于REQUIRED。
回滚：方法B的事务独立运行，回滚仅限于方法B。

----------------------------------------------------------------------------------

3. 方法A和方法B都有事务

在这种情况下，两个方法都有事务，因此传播机制决定它们是否共享同一个事务，或者在独立事务中执行。

3.1 Propagation.REQUIRED

调用流程：方法A和方法B都有事务。
行为：方法B会加入方法A的事务，二者共享同一个事务。
回滚：如果方法A回滚，方法B的操作也会回滚，反之亦然。

3.2 Propagation.REQUIRES_NEW

调用流程：方法A和方法B都有事务。
行为：方法B会启动一个新的事务，方法A的事务会被挂起。二者在独立的事务中执行。
回滚：方法A和方法B的回滚互不影响。

3.3 Propagation.SUPPORTS

调用流程：方法A和方法B都有事务。
行为：方法B会加入方法A的事务，二者共享同一个事务。
回滚：如果方法A回滚，方法B的操作也会回滚，反之亦然。

3.4 Propagation.NOT_SUPPORTED

调用流程：方法A和方法B都有事务。
行为：方法B会暂停方法A的事务，在无事务的上下文中执行。
回滚：方法B的操作不受事务控制，方法A的回滚不影响方法B的操作。

3.5 Propagation.MANDATORY

调用流程：方法A和方法B都有事务。
行为：方法B会加入方法A的事务，二者共享同一个事务。
回滚：如果方法A回滚，方法B的操作也会回滚，反之亦然。

3.6 Propagation.NEVER

调用流程：方法A和方法B都有事务。
行为：方法B拒绝在事务中执行，因此会抛出异常。
回滚：方法B不会执行，直接抛出异常。

3.7 Propagation.NESTED

调用流程：方法A和方法B都有事务。
行为：方法B会启动一个嵌套事务，方法A和方法B共享相同的事务边界，但方法B的操作可以独立回滚。
回滚：方法B回滚时不影响方法A，方法A回滚时方法B的嵌套事务也会回滚。

以上就是在不同场景下的传播行为会出现的情况，大家可以稍微消化以下~

接下来就是隔离性了~

隔离性

隔离性我们就要说到隔离级别了，在事务中有五种隔离级别：

DEFAULT：Spring 中默认的事务隔离级别，以连接的数据库的事务隔离级别为准；
READ_UNCOMMITTED：读未提交，也叫未提交读，该隔离级别的事务可以看到其他事务中未提交的数据。该隔离级别因为可以读取到其他事务中未提交的数据，而未提交的数据可能会发生回滚，因此我们把该级别读取到的数据称之为脏数据，把这个问题称之为脏读；
READ_COMMITTED：读已提交，也叫提交读，该隔离级别的事务能读取到已经提交事务的数据，因此它不会有脏读问题。但由于在事务的执行中可以读取到其他事务提交的结果，所以在不同时间的相同 SQL 查询中，可能会得到不同的结果，这种现象叫做不可重复读；
REPEATABLE_READ：可重复读，它能确保同一事务多次查询的结果一致。但也会有新的问题，比如此级别的事务正在执行时，另一个事务成功的插入了某条数据，但因为它每次查询的结果都是一样的，所以会导致查询不到这条数据，自己重复插入时又失败（因为唯一约束的原因）。明明在事务中查询不到这条信息，但自己就是插入不进去，这就叫幻读（Phantom Read）；
SERIALIZABLE：串行化，最高的事务隔离级别，它会强制事务排序，使之不会发生冲突，从而解决了脏读、不可重复读和幻读问题，但因为执行效率低，所以真正使用的场景并不多。