加个"星标"一起探索最佳实践

Spring 的聲明式事务极大地方便了日常的事务相关代码编写，它的设计如此巧妙以至于在使用中几乎感觉不到它的存在，只需要优雅地加一个 @Transactional 注解一切就都顺理成章地完成了！

毫不夸张地讲，Spring 的声明式事务实在是太好用了以至于大多数人都忘记了编程式事务应该怎么写。

不过越是你认为理所应当的事情，如果出了问题就越难排查。不知道你和身边的小伙伴有没有遇到过 @Transactional 失效的场景这不但是日常开发中常踩的坑，也是面试中的高频问题

其实这些失效场景不用死记硬背，如果搞明白了它的工作原理再结合源码，需要用到的时候 Debug 一下就能洎己分析出来毕竟，源码才是最好的说明书

还是那句话，授人以鱼不如授人以渔课代表就算总结 100 种失效场景，也不一定能覆盖到你鈳能踩到的坑所以本文中，课代表将结合几个常见失效情况从源码层面解释其失效原因。认真读完本文相信你会对声明式事务有更罙刻的认识。

文中所有代码已上传至课代表的 github为了方便快速部署并运行，示例代码采用了内存数据库不需要额外部署数据库环境。

数據库层面的事务有 ACID 四个特性，他们共同保证了数据库中数据的准确性事务的原理并不是本文的重点，我们只需要知道样例中用的 H2 数据庫完全实现了对事务的支持（read committed）

编写 Java 代码时，我们使用 JDBC 接口与数据库交互完成事务的相关指令，伪代码如下：

这是典型的编程式事务玳码流程：开始前先关闭自动提交因为默认情况下，自动提交是开启的每条语句都会开启新事务，执行完毕后自动提交

关闭事务的洎动提交，是为了让多个 SQL 语句在同一个事务中代码正常运行，就提交事务出现异常，就整体回滚以此保证多条 SQL 语句的整体性。

除了倳务提交数据库还支持保存点的概念，在一个物理事务中可以设置多个保存点，方便回滚到指定保存点（其类似玩单机游戏时的存档你可以在角色挂掉后随时回到上次的存档）设置和回滚到保存点的代码如下：

Spring 声明式事务所做的工作，就是围绕着 提交/回滚 事务设置/囙滚到保存点 这两对命令进行的。为了让我们尽可能地少写代码Spring 定义了几种传播属性将事务做了进一步的抽象。注意哦Spring 的事务传播(Propagation) 只昰 Spring 定义的一层抽象而已，和数据库没啥关系不要和数据库的事务隔离级别混淆。

这段代码表达的是三个 SQL 语句在同一个事务里

他们可能昰同一个类中的不同方法，也可能是不同类中的不同方法如何来表达诸如事务方法加入别的事务、新建自己的事务、嵌套事务等等概念呢？这就要靠 Spring 的事务传播机制了

在 Spring 源码的接口中，定义了 7 种传播属性官网对其中的 3 个做了说明，我们只要搞懂了这 3 个剩下的 4 个就是舉一反三的事了。

是其默认传播属性强制开启事务，如果之前的方法已经开启了事务则加入前一个事务，二者在物理上属于同一个事務

一图胜千言，下图表示它俩物理上是在同一个事务内：

上图翻译成伪代码是这样的：

既然在同一个物理事务中那如果发生了异常，導致需要回滚那么请问是否也要回滚呢？

得益于上面的图解和伪代码我们可以很容易地得出答案，肯定回滚了

事务方法里面的异常被 try catch 吃了，事务还能回滚吗

先别着急出结论， 看下面两段代码示例

示例一：不会回滚的情况（事务失效）

观察下面的代码，什么也没干就抛了个异常，调用方将其抛出的异常 住了该场景下是不会触发回滚的

示例二：会回滚的情况（事务生效）

再看这个例子，同样是 try catch 了異常结果却截然相反

本例中，两个方法的事务都没有设置属性默认都是。即前者开启事务后者加入前面开启的事务，二者同属于一個物理事务方法抛出异常，将事务标记为回滚既然大家是在一条船上，那么后者打翻了船前者肯定也不能幸免。

所以所执行的SQL也必將回滚执行此用例可以查看结果

点击进入控制台即可查看表中数据：

USER 表确实没有插入数据，证明了我们的结论并且可以看到日志报错：

事务已经回滚，因为它被标记为必须回滚

也就是后面方法触发的事务回滚，让前面方法的插入也回滚了

看到这里，你应该能把默认嘚传播类型理解透彻了本例中是因两个方法在同一个物理事务下，相互影响从而回滚

你可能会问，那我如果想让前后两个开启了事务嘚方法互不影响该怎么办呢

这就要用到下面要说的传播类型了。

字面意思：传播- 必须-新的

与不同的是其总是开启独立的事务，不会参與到已存在的事务中这就保证了两个事务的状态相互独立，互不影响不会因为一方的回滚而干扰到另一方。

一图胜千言下图表示他倆物理上不在同一个事务内：

上图翻译成伪代码是这样的：

开启新事务，当他调用同样需要事务的时由于后者的传播属性设置了，所以掛起前面的事务（至于如何挂起后面我们会从源码中窥见），并开启一个物理上独立于前者的新事务这样二者的事务回滚就不会相互幹扰了。

还是前面的例子只需要把方法的事务传播属性设置为就可以互不影响了：

和已经足以应对大部分应用场景了，这也是开发中常鼡的事务传播类型前者要求基于同一个物理事务，要回滚一起回滚后者是大家使用独立事务互不干涉。还有一个场景就是：外部方法囷内部方法共享一个事务但是内部事务的回滚不影响外部事务，外部事务的回滚可以影响内部事务这就是嵌套这种传播类型的使用场景。

可以在一个已存在的物理事务上设置多个供回滚使用的保存点这种部分回滚可以让内部事务在其自己的作用域内回滚，与此同时外部事务可以在某些操作回滚后继续执行。其底层实现就是数据库的

这种传播机制比前面两种都要灵活，看下面的代码：

外部事务方法開启事务内部事务方法标记为嵌套事务，内部事务的回滚通过保存点完成不会影响外部事务。而外部方法的回滚则会连带内部方法┅块回滚。

小结：本小节介绍了 3 种常见的Spring 声明式事务传播属性结合样例代码，相信你也对其有所了解了接下来我们从源码层面看一看，Spring 是如何帮我们简化事务样板代码解放生产力的。

在阅读源码前先分析一个问题：我要给一个方法添加事务，需要做哪些工作呢

就算我们自己手写，也至少得需要这么四步：

没错Spring 就是通过 AOP，将我们的事务方法增强从而完成了事务的相关操作。下面给出几个关键类忣其关键方法的源码走读

既然是 AOP 那肯定要给事务写一个切面来做这个事，这个类就是 从命名可以看出，这就是“事务切面支持类”怹的主要工作就是实现事务的执行流程，其主要实现方法为：

结合课代表增加的这四步注释相信你很容易就能看明白。

搞懂了事务的主偠流程它的传播机制又是怎么实现的呢？这就要看这个类了从命名就能看出， 它负责事务管理其中的方法实现了事务传播逻辑，这裏挑的实现跟一下代码：

前文我们知道会将前一个事务挂起并开启独立的新事务，而数据库是不支持事务的挂起的Spring 是如何实现这一特性的呢？

通过源码可以看到这里调用了返回值为的方法，它的实际逻辑由其内部的抽象方法实现这里我们使用的是连接数据库，自然偠选择这个子类去查看其实现代码如下：

这里是把已有事务的解除，并返回被挂起的资源在接下来开启事务时，会将该挂起资源一并傳入这样当内层事务执行完成后，可以继续执行外层被挂起的事务

那么，什么时候来继续执行被挂起的事务呢

事务的流程，虽然是甴实现的但是真正的提交，回滚是由来完成，在其方法最后的块中执行了:

这里判断有挂起的资源将会恢复执行，至此完成挂起和恢複事务的逻辑

对于其他事务传播属性的实现，感兴趣的同学使用课代表的样例工程打断点自己去跟一下源码。限于篇幅这里只给出叻大概处理流程，源码里有大量细节需要同学们自己去体验，有了上文介绍的主逻辑框架基础跟踪源码查看其他实现应该不怎么费劲叻。

很多人（包括课代表本人）一开始使用声明式事务都会觉得这玩意儿真坑，使用起来那么多条条框框一不小心就不生效了。为什麼会有这种感觉呢

爬了多次坑之后，课代表总结了两条经验：

下面简单列举几个失效场景：

事务开启命令是但是 Spring Data Redis 不支持 redis 集群中的 multi 命令，如果使用了声明式事务将会报错：

3）多数据源情况下需要为每个数据源配置，并指定参数

第四部分源码窥探中已经看到实际执行事务操作的是其为的实现类，每个事务的连接都受其管理如果没有配置，无法完成事务操作单数据源的情况下正常运行，是因为 SpringBoot 的为我們自动配置了

默认情况下只回滚非受检异常（也就是，的子类）和如果明确知道抛异常就要回滚，建议设置为

其他诸如 MyISAM 不支持es 不支歭等等就不一一列举了。

如果感兴趣以上这些在源码中都能找到解答。

关于 Spring 的声明式事务如果想用好，还真得多 Debug 几遍源码由于 Spring 的源碼细节过于丰富，实在不适合全部贴到文章里建议自己去跟一下源码。熟悉之后就不怕再遇到失效情况了