Spring源码解析之事务篇

什么是事务？

事务（Transaction）：指访问并可能更新数据库中各种数据项的一个程序执行单元(unit)，它是恢复和并发控制的基本单位。

通常我们在业务逻辑处理代码中对数据库的同一组增删改查操作就是一个事务操作，由此可见事务的前提必须是使用的数据库的底层支持，但是并不是所有的数据库（准确来说是存储引擎，因为数据库持久化的底层是对磁盘读写的操作）都支持事务操作。

因此Spring中支持的事务其实是对数据库事务的一种代理封装，具体的事务操作必须依赖所使用的数据库提供的开放API；以常见的数据库MySQL为例，Spring使用MySQL事务的前提需要导入mysql-connector-java依赖包，它就是MySQL用Java语言开发的客户端应用程序，它提供了数据库的API及许多增值扩展。

那这意味着什么呢？

这意味着你完全可以基于它来自定义封装一个事务框架，甚至是分布式事务框架，万丈高楼平地起，发展空间很大哦 ^_。

准备工作

既然已经知道了Spring事务的由来，那我们还需要了解Spring中事务的一些基础知识。

特性

事务应该具有的4个属性，我们称为ACID特性：

• 原子性（Automicity）：一个事务操作中不可分割的最小工作单位，要么都成功，要么都失败。
• 一致性（Consistency）：事务前后的数据必须保证完整一致性。
• 隔离性（Isolation）：各个事务之间的执行操作是相互隔离且互不影响的。
• 持久性（Durability）：一个事务一旦提交，对数据库中数据的改变是永久性的，不会被回滚。

并发问题

通常执行程序在多核CPU中会发生并发执行，因此带来了多线程的并发问题，而事务在并发情况下同样也会带来读一致性的问题，像以下3种：

• 脏读：在一个事务中执行insert、update、delete操作，但是还未提交，另外一个事务读取了未提交的数据，一旦前面事务发生回滚，那么后面的事务就产生了脏读。
• 不可重复读：在一个事务中发生的两次读操作中间，另一个事务对数据进行了update或delete操作，导致两次读取数据结果不一致的问题。
• 幻读：在一个事务执行select、insert、update、delete操作时，另外一个事务进行了insert操作，这时前面的事务会无法操作新增的数据，从而产生幻读问题。

隔离级别

上面描述了并发环境下事务会产生的问题，再结合前面介绍的特性，能知道通过隔离性能很好地解决这些问题，而在数据库中支持4种隔离级别：

• 未提交读（Read-Uncommitted）：未提交的事务操作数据允许被其他事务读取到，它能导致脏读、不可重复读、幻读的问题。

• 已提交读（Read-Committed）：已提交的事务操作数据才允许被其他事务读取到，它能导致不可重复读、幻读的问题。

• 可重复读（Repeatable-Read）：它在已提交读的基础上解决了不可重复读的问题，但是还是会产生幻读的问题。

• 串行化（Serializable）：所有事务必须串行化一个一个执行，不能并发执行，避免了脏读、不可重复读、幻读的问题，但是严重影响执行效率。

Spring中默认配置隔离级别是使用的数据库的默认级别，而MySQL中默认的隔离级别为可重复读，同时默认的隔离级别在MySQL5.6版本开始的InnoDB存储引擎中也已经通过临键间隙锁(Next-Key锁)解决幻读的问题；而上面的隔离级别从上往下越能保证数据的完整性和一致性，但是并发性能却越来越低。

传播行为

Spring的传播行为，就是在实际业务代码开发中，同时存在多个事务时，Spring应该怎样去处理这些事务的行为。这些传播属性定义在类TransactionDefinition中，分别是以下7种：

• PROPAGATION_REQUIRED：如果当前存在事务，则加入该事务；如果当前没有事务，则创建一个新的事务。
• PROPAGATION_SUPPORTS：如果当前存在事务，则加入该事务；如果当前没有事务，则以非事务的方式继续运行。
• PROPAGATION_MANDATORY：如果当前存在事务，则加入该事务；如果当前没有事务，则抛出异常。
• PROPAGATION_REQUIRES_NEW：创建一个新的事务，如果当前存在事务，则把当前事务挂起。
• PROPAGATION_NOT_SUPPORTED：以非事务方式运行，如果当前存在事务，则把当前事务挂起。
• PROPAGATION_NEVER： 以非事务方式运行，如果当前存在事务，则抛出异常。
• PROPAGATION_NESTED：如果当前存在事务，则创建一个事务作为当前事务的嵌套事务来运行；如果当前没有事务，则该取值等价于TransactionDefinition.PROPAGATION_REQUIRED。

而Spring中默认的传播行为为PROPAGATION_REQUIRED，实际开发中，我们使用@Transactional来启用注解，其中的propagation属性可以进行事务传播行为的配置，而属性值就是Propagation枚举类来定义的。

声明式配置

Spring中对于数据库事务支持声明式事务和编程式事务，不管是实际开发还是Spring官方都推荐使用声明式事务，因为它对应用程序代码的侵入性最小；它有两种配置方式：

• 基于XML的配置：在XML中通过标签指定的各种事务设置。
• 基于注解的配置：在代码中使用@Transactional注解配置，这也是实际开发中最常用的方式。

这两种方式默认设置如下：

• 传播行为是REQUIRED；
• 隔离级别为 DEFAULT；
• 事务是读写的；
• 事务超时默认为底层事务系统的默认超时，如果不支持超时，则无；
• 任何RuntimeException触发器都会回滚，任何检查Exception都不会。

事务的流程

通常我们在开发中对数据库的执行操作的是通过集成第三方ORM框架完成的，像MyBatis、JPA、Hibernate等，而非Spring自带的封装实现；但是通常为了方便使用，数据源及事务管理等还是会交给Spring去统一管理。

这里我们基于Mysql数据库、注解式事务提供一个简单的Demo来作为入口去解析源码中事务的执行流程。

@Configuration
@EnableTransactionManagement
public class Config {
    
    @Bean
    public DataSource setDataSource(){
        DriverManagerDataSource dataSource = new DriverManagerDataSource();
        dataSource.setDriverClassName("com.mysql.jdbc.Driver");
        dataSource.setUrl("jdbc:mysql://localhost:3306/test");
        dataSource.setUsername("root");
        dataSource.setPassword("123456");
        return dataSource;
    }
    
    @Bean
    public PlatformTransactionManager setPlatformTransactionManager(DataSource dataSource) {
        return new DataSourceTransactionManager(dataSource);
    }
    
    @Bean
    public JdbcTemplate setJdbcTemplate(DataSource dataSource) {
        return new JdbcTemplate(dataSource);
    }
}

@Service
public class UserService {
    @Autowired
    private JdbcTemplate jdbcTemplate;
    
    @Transactional(rollbackFor = Exception.class)
    public void handle(){
        jdbcTemplate.update("insert into user(user_name,phone) values(?,?)","张三","13212312341");
        update();
    }
    
    @Transactional(rollbackFor = Exception.class)
    public void update(){
        jdbcTemplate.update("update user set phone = ? where id = ?","11122223333",2);
    }
}

public class Test {

    public static void main(String[] args) {
        AnnotationConfigApplicationContext ac = new AnnotationConfigApplicationContext("com.test.spring.transaction");
        UserService userService = ac.getBean(UserService.class);
        userService.handle();
    }
}

在解析事务的处理过程前，我们需要提前做好两步工作：

1. 配置数据源DataSource；
2. 定义事务管理器PlatformTransactionManager；

事务管理器

我们知道所有对数据库的操作都是基于API来实现的，所以得先通过配置数据源来连接数据库，那么第二步的事务管理器的作用是什么？

首先事务管理器是Spring提供的一种事务的抽象编程模型，它可以跨不同事务API，同时提供了声明示事务的支持；我们可以理解为它就是一个顶层的事务管理接口，我们可以基于它的实现很好地集成到Spring框架中去使用事务。

而Spring中的事务管理类型分为两种：

• 命令式：PlatformTransactionManager，与@Transactional配合使用，管理同一个线程绑定的一些列事务操作。
• 反应式：ReactiveTransactionManager，提供Reactive反应式编程中事务管理，使用 Reactor 上下文执行事务操作。

通常我们使用的就是PlatformTransactionManager，我们先看下它的源码，

public interface PlatformTransactionManager {
    //获取事务执行和查询状态
    TransactionStatus getTransaction(@Nullable TransactionDefinition var1) throws TransactionException;
    //事务提交
    void commit(TransactionStatus var1) throws TransactionException;
    //事务回滚
    void rollback(TransactionStatus var1) throws TransactionException;
}

它是一个顶层接口，定义了几个模板方法，将开发中业务逻辑代码和数据库事务相关执行代码进行了拆分，降低了代码之间的耦合性，提高了复用性。

我们通过它的类图能看到已经提供了很多子类实现，它们各自的作用这里不一一介绍了，感兴趣的可以去了解下。

image.png

启用流程

在解析了一些相关Spring源码过程中，相信已经发现，基本任何有关Spring的源码解析都绕不开Spring的IOC容器初始化过程。

这里同样也是，我们先在如下图位置进行断点debug，

image.png

发现这里的UserService对象实际是一个通过CGLIB代理的对象，首先可以想到这里的UserService因为没有实现接口，所以是通过CGLIB，而非使用JDK进行的动态代理；但是我们的Demo中好像并没有启用AOP及使用任何切点、切面的配置，只在方法上加了@Transactional注解，为什么这里从IOC容器中获取的是一个代理对象呢？难道@Transactional注解其实就是一个切点？

没错，Spring中事务的前提就是基于AOP的支持来实现的，那看样子我们需要从IOC及AOP的初始化过程中进行探究了，而之前我们已经解析了它们各自的初始化过程，相信从中找出有关事务相关代理流程应该不是问题。

Demo中我们在Config配置中加了@EnableTransactionManagement注解，它是用来启用事务管理器，看它的源码，

@Target({ElementType.TYPE})
@Retention(RetentionPolicy.RUNTIME)
@Documented
@Import({TransactionManagementConfigurationSelector.class})
public @interface EnableTransactionManagement {
    //强制使用CGLIB代理
    boolean proxyTargetClass() default false;
    //通知类型：代理、AspectJ
    AdviceMode mode() default AdviceMode.PROXY;

    int order() default 2147483647;
}

是不是发现和@EnableAspectJAutoProxy有点类似，这里的属性值分别为：

• proxyTargetClass：默认false，Spring会根据被代理对象的实现接口情况去自动选择JDK或者CGLIB动态代理机制；设置为true时，代表代理机制强制使用CGLIB动态代理，但这样会导致无法对final修饰的方法进行拦截通知，因为它不能被覆写。
• AdviceMode：支持PROXY和AspectJ两种类型，默认为PROXY。
• order：加载顺序。

而这里通过@Import的TransactionManagementConfigurationSelector类的源码，

public class TransactionManagementConfigurationSelector extends AdviceModeImportSelector {
    public TransactionManagementConfigurationSelector() {
    }

    protected String[] selectImports(AdviceMode adviceMode) {
        switch(adviceMode) {
        case PROXY:
            return new String[]{AutoProxyRegistrar.class.getName(), ProxyTransactionManagementConfiguration.class.getName()};
        case ASPECTJ:
            return new String[]{"org.springframework.transaction.aspectj.AspectJTransactionManagementConfiguration"};
        default:
            return null;
        }
    }
}

它的顶层父类是ImportSelector，而ImportSelector的作用是：在添加@Configuration注解的Class上使用@Import去引入了一个ImportSelector的实现子类后，会把实现类中selectImports()方法返回的ClassName都定义为Bean对象。

所以默认AdviceMode=PROXY时，它会根据根据AdviceMode类型选择加载注册AutoProxyRegistrar、ProxyTransactionManagementConfiguration对象。

启用代理

我们先看下AutoProxyRegistrar的类图，[图片上传失败...(image-a9e0ac-1632446770718)]

发现它和AspectJAutoProxyRegistrar一样都是ImportBeanDefinitionRegistrar的实现子类，而在AOP的源码解析中我们知道AOP自动代理的启用就是通过AspectJAutoProxyRegistrar来注册AnnotationAwareAspectJAutoProxyCreator完成的，而这里通过AutoProxyRegistrar注册InfrastructureAdvisorAutoProxyCreator来完成的，通过下面的类图我们就知道了，它们都是BeanPostProcessor的实现子类。

[图片上传失败...(image-14b47a-1632446770718)]

事务管理配置定义

在看下ProxyTransactionManagementConfiguration的源码，

@Configuration
public class ProxyTransactionManagementConfiguration extends AbstractTransactionManagementConfiguration {
    public ProxyTransactionManagementConfiguration() {
    }

    @Bean(name = {"org.springframework.transaction.config.internalTransactionAdvisor"})
    @Role(2)
    public BeanFactoryTransactionAttributeSourceAdvisor transactionAdvisor() {
        BeanFactoryTransactionAttributeSourceAdvisor advisor = new BeanFactoryTransactionAttributeSourceAdvisor();
        advisor.setTransactionAttributeSource(this.transactionAttributeSource());
        advisor.setAdvice(this.transactionInterceptor());
        if (this.enableTx != null) {
            advisor.setOrder((Integer)this.enableTx.getNumber("order"));
        }
        return advisor;
    }

    @Bean
    @Role(2)
    public TransactionAttributeSource transactionAttributeSource() {
        return new AnnotationTransactionAttributeSource();
    }

    @Bean
    @Role(2)
    public TransactionInterceptor transactionInterceptor() {
        TransactionInterceptor interceptor = new TransactionInterceptor();
        interceptor.setTransactionAttributeSource(this.transactionAttributeSource());
        if (this.txManager != null) {
            interceptor.setTransactionManager(this.txManager);
        }
        return interceptor;
    }
}

// 父类
@Configuration
public abstract class AbstractTransactionManagementConfiguration implements ImportAware {
    @Nullable
    protected AnnotationAttributes enableTx;
    @Nullable
    protected PlatformTransactionManager txManager;

    public AbstractTransactionManagementConfiguration() {
    }

    public void setImportMetadata(AnnotationMetadata importMetadata) {
        this.enableTx = AnnotationAttributes.fromMap(importMetadata.getAnnotationAttributes(EnableTransactionManagement.class.getName(), false));
        if (this.enableTx == null) {
            throw new IllegalArgumentException("@EnableTransactionManagement is not present on importing class " + importMetadata.getClassName());
        }
    }

    @Autowired(required = false)
    void setConfigurers(Collection configurers) {
        if (!CollectionUtils.isEmpty(configurers)) {
            if (configurers.size() > 1) {
                throw new IllegalStateException("Only one TransactionManagementConfigurer may exist");
            } else {
                TransactionManagementConfigurer configurer = (TransactionManagementConfigurer)configurers.iterator().next();
                this.txManager = configurer.annotationDrivenTransactionManager();
            }
        }
    }

    @Bean(name = {"org.springframework.transaction.config.internalTransactionalEventListenerFactory"})
    @Role(2)
    public TransactionalEventListenerFactory transactionalEventListenerFactory() {
        return new TransactionalEventListenerFactory();
    }
}

一共定义了以下4个Bean对象：

• TransactionalEventListenerFactory：创建事务事件监听器的工厂类。
• TransactionInterceptor：事务处理的拦截器。
• AnnotationTransactionAttributeSource：用于处理事务元数据的接口。
• BeanFactoryTransactionAttributeSourceAdvisor：事务中事务方法的通知。

现在可能难以理解它们实际的作用，但是继续往下解析，你就会知道它们在后面代理类的生成以及代理方法执行过程中锁发挥的作用。

生成代理类

再结合之前解析的IOC及AOP的初始化流程，代理类的生成流程大致如下：

1. 通过InfrastructureAdvisorAutoProxyCreator对Bean进行前后置处理（Demo中UserService将@Transactionl注解添加在方法上，会在Bean初始化后调用applyBeanPostProcessorsAfterInitialization()方法进行回调处理）；
2. 获取BeanFactoryTransactionAttributeSourceAdvisor通知对Bean的类及方法上的解析@Transactional注解进行匹配；
3. 从BeanFactoryTransactionAttributeSourceAdvisor中获取AnnotationTransactionAttributeSource对@Transactional中设置的属性进行解析处理；
4. 讲解析后的属性缓存到RuleBasedTransactionAttribute中，像事务的传播行为、隔离机制、回滚规则等。
5. 对满足通知切点规则的Bean进行动态代理，生成代理类。

[图片上传失败...(image-4f1792-1632446770718)]

处理流程

这里我们对数据库的访问操作使用的是Spring自己的模板封装类JdbcTemplate，当然除了它还有其他模板类，像NamedParameterJdbcTemplate、SimpleJdbcInsert、SimpleJdbcCall、RDBMS 对象（包括MappingSqlQuery、SqlUpdate和StoredProcedure），根据自己的选择需求选择即可。

由于我们Demo中UserService使用的是CGLIB动态代理，所以在执行handle()方法的时候，实际调用的是CglibAopProxy类中的intercept()方法，

        @Nullable
        public Object intercept(Object proxy, Method method, Object[] args, MethodProxy methodProxy) throws Throwable {
            Object oldProxy = null;
            boolean setProxyContext = false;
            Object target = null;
            TargetSource targetSource = this.advised.getTargetSource();
            Object var16;
            try {
                if (this.advised.exposeProxy) {
                    oldProxy = AopContext.setCurrentProxy(proxy);
                    setProxyContext = true;
                }
                target = targetSource.getTarget();
                Class targetClass = target != null ? target.getClass() : null;
                //获取拦截器链
                List