前言

Spring框架已是JAVA项目的标配，其中Spring事务管理也是最常用的一个功能，但如果不了解其实现原理，使用姿势不对，一不小心就可能掉坑里。

为了更透彻的说明这些坑，本文分四部分展开阐述：第一部分简单介绍下Spring事务集成的几种方式；第二部分结合Spring源代码说明Spring事务的实现原理；第三部分通过实际测试代码介绍关于Spring事务的坑；第四部分是对本文的总结。

一、Spring事务管理的几种方式：

Spring事务在具体使用方式上可分为两大类：

1. 声明式

基于 TransactionProxyFactoryBean的声明式事务管理

基于 和 命名空间的事务管理

基于 @Transactional 的声明式事务管理

2. 编程式

基于事务管理器API 的编程式事务管理

基于TransactionTemplate 的编程式事务管理

目前大部分项目使用的是声明式的后两种：

基于 和 命名空间的声明式事务管理可以充分利用切点表达式的强大支持，使得管理事务更加灵活。 基于 @Transactional 的方式需要实施事务管理的方法或者类上使用 @Transactional 指定事务规则即可实现事务管理，在Spring Boot中通常也建议使用这种注解方式来标记事务。

二、Spring事务实现机制

接下来我们详细看下Spring事务的源代码，进而了解其工作原理。我们从标签的解析类开始：

由此可看到Spring事务的核心实现类TransactionInterceptor及其父类TransactionAspectSupport，其实现了事务的开启、数据库操作、事务提交、回滚等。我们平时在开发时如果想确定是否在事务中，也可以在该方法进行断点调试。

TransactionInterceptor：

TransactionAspectSupport

至此我们了解事务的整个调用流程，但还有一个重要的机制没分析到，那就是Spring 事务针对不同的传播级别控制当前获取的数据库连接。接下来我们看下Spring获取连接的工具类DataSourceUtils，JdbcTemplate、Mybatis-Spring也都是通过该类获取Connection。

TransactionSynchronizationManager也是一个事务同步管理的核心类，它实现了事务同步管理的职能，包括记录当前连接持有connection holder。
TransactionSynchronizationManager

在事务管理器类AbstractPlatformTransactionManager中，getTransaction获取事务时，会处理不同的事务传播行为，例如当前存在事务，但调用方法事务传播级别为REQUIRES_NEW、PROPAGATION_NOT_SUPPORTED时，对当前事务进行挂起、恢复等操作，以此保证了当前数据库操作获取正确的Connection。

具体是在子事务提交的最后会将挂起的事务恢复，恢复时重新调用TransactionSynchronizationManager. bindResource设置之前的connection holder，这样再获取的连接就是被恢复的数据库连接， TransactionSynchronizationManager当前激活的连接只能是一个。

AbstractPlatformTransactionManager

Spring的事务是通过AOP代理类中的一个Advice（TransactionInterceptor）进行生效的，而传播级别定义了事务与子事务获取连接、事务提交、回滚的具体方式。

AOP（Aspect Oriented Programming），即面向切面编程。Spring AOP技术实现上其实就是代理类，具体可分为静态代理和动态代理两大类，其中静态代理是指使用 AOP 框架提供的命令进行编译，从而在编译阶段就可生成 AOP 代理类，因此也称为编译时增强；(AspectJ)；而动态代理则在运行时借助于 默写类库在内存中“临时”生成 AOP 动态代理类，因此也被称为运行时增强。其中java是使用的动态代理模式 (JDK+CGLIB)。

JDK动态代理 JDK动态代理主要涉及到java.lang.reflect包中的两个类：Proxy和InvocationHandler。InvocationHandler是一个接口，通过实现该接口定义横切逻辑，并通过反射机制调用目标类的代码，动态将横切逻辑和业务逻辑编制在一起。Proxy利用InvocationHandler动态创建一个符合某一接口的实例，生成目标类的代理对象。

CGLIB动态代理 CGLIB全称为Code Generation Library，是一个强大的高性能，高质量的代码生成类库，可以在运行期扩展Java类与实现Java接口，CGLIB封装了asm，可以再运行期动态生成新的class。和JDK动态代理相比较：JDK创建代理有一个限制，就是只能为接口创建代理实例，而对于没有通过接口定义业务方法的类，则可以通过CGLIB创建动态代理。

CGLIB 创建代理的速度比较慢，但创建代理后运行的速度却非常快，而 JDK 动态代理正好相反。如果在运行的时候不断地用 CGLIB 去创建代理，系统的性能会大打折扣。因此如果有接口，Spring默认使用JDK 动态代理，源代码如下：

在了解Spring代理的两种特点后，我们也就知道在做事务切面配置时的一些注意事项，例如JDK代理时方法必须是public，CGLIB代理时必须是public、protected，且类不能是final的；在依赖注入时，如果属性类型定义为实现类，JDK代理时会报如下注入异常：

但如果修改为CGLIB代理时则会成功注入，所以如果有接口，建议注入时该类属性都定义为接口。另外事务切点都配置在实现类和接口都可以生效，但建议加在实现类上。

官网关于Spring AOP的详细介绍

docs.spring.io/spring/docs…

三、Spring事务的那些坑

通过之前章节，相信您已经掌握了spring事务的使用方式与原理，不过还是要注意，因为一不小心就可能就掉坑。首先看第一个坑：

3.1 事务不生效

测试代码，事务AOP配置：

1.运行输出：

2.运行输出：

3.运行输出：
insertAccount connection hashcode=303240439 insertStock connection hashcode=303240439可以看到2、3测试方法跟我们事务预期并一样，结论：调用方法未配置事务、本类方法直接调用，事务都不生效！

究其原因，还是因为Spring的事务本质上是个代理类，而本类方法直接调用时其对象本身并不是织入事务的代理，所以事务切面并未生效。具体可以参见#Spring事务实现机制#章节。

Spring也提供了判断是否为代理的方法：

那如何修改为代理类调用呢？最直接的想法是注入自身，代码如下：

当然Spring提供了获取当前代理的方法：代码如下：

另外Spring是通过TransactionSynchronizationManager类中线程变量来获取事务中数据库连接，所以如果是多线程调用或者绕过Spring获取数据库连接，都会导致Spring事务配置失效。

最后Spring事务配置失效的场景：
事务切面未配置正确
本类方法调用
多线程调用
绕开Spring获取数据库连接
接下来我们看下Spring的事务的另外一个坑:

3.2 事务不回滚

测试代码：

输出结果：

insertAccount connection hashcode=656479172 updateAccount connection hashcode=517355658 account balance is 8000.0应用抛出异常，但accountDao.updateAccount却进行了提交。究其原因，直接看Spring源代码：

TransactionAspectSupport

由代码可见，Spring事务默认只对RuntimeException和Error进行回滚，如果应用需要对指定的异常类进行回滚，可配置rollback-for=属性，例如：

事务不回滚的原因：
事务配置切面未生效
应用方法中将异常捕获
抛出的异常不属于运行时异常（例如IOException），
rollback-for属性配置不正确

接下来我们看下Spring事务的第三个坑：

3.3 事务超时不生效

测试代码：

正常运行，事务超时未生效

抛出事务超时异常，超时生效

org.springframework.transaction.TransactionTimedOutException: Transaction timed out: deadline was Fri Nov 23 17:03:02 CST 2018 at org.springframework.transaction.support.ResourceHolderSupport.checkTransactionTimeout(ResourceHolderSupport.java:141) …

通过源码看看Spring事务超时的判断机制：

ResourceHolderSupport

通过查看getTimeToLiveInMillis方法的Call Hierarchy，可以看到被DataSourceUtils的applyTimeout所调用， 继续看applyTimeout的Call Hierarchy，可以看到有两处调用，一个是JdbcTemplate，一个是TransactionAwareInvocationHandler类，后者是只有TransactionAwareDataSourceProxy类调用，该类为DataSource的事务代理类，我们一般并不会用到。难道超时只能在这调用JdbcTemplate中生效？写代码亲测：

运行正常，事务超时失效

由上可见：Spring事务超时判断在通过JdbcTemplate的数据库操作时，所以如果超时后未有JdbcTemplate方法调用，则无法准确判断超时。另外也可以得知，如果通过Mybatis等操作数据库，Spring的事务超时是无效的。鉴于此，Spring的事务超时谨慎使用。

四、 总结

JDBC规范中Connection 的setAutoCommit是原生控制手动事务的方法，但传播行为、异常回滚、连接管理等很多技术问题都需要开发者自己处理，而Spring事务通过AOP方式非常优雅的屏蔽了这些技术复杂度，使得事务管理变的异常简单。

但凡事有利弊，如果对实现机制理解不透彻，很容易掉坑里。最后总结下Spring事务的可能踩的坑：

1. Spring事务未生效

调用方法本身未正确配置事务
本类方法直接调用
数据库操作未通过Spring的DataSourceUtils获取Connection
多线程调用

2. Spring事务回滚失效

未准确配置rollback-for属性
异常类不属于RuntimeException与Error
应用捕获了异常未抛出

3. Spring事务超时不准确或失效

超时发生在最后一次JdbcTemplate操作之后
通过非JdbcTemplate操作数据库，例如Mybatis

了解更多，请点击：https://www.bilibili.com/video/BV1L7411N77n

作者：你丫才CRUD
链接：https://juejin.cn/post/6900794629814550536
来源：掘金
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。