（七）Spring源码解析：Spring事务

对于事务来说，是我们平时在基于业务逻辑编码过程中不可或缺的一部分，它对于保证业务及数据逻辑原子性立下了汗马功劳。那么，我们基于Spring的声明式事务，可以方便我们对事务逻辑代码进行编写，那么在开篇的第一部分，我们就来用一个示例，来演示一下Spring事务的编写方式。

一、事务使用示例

首先添加Maven依赖

	commons-dbcp
	commons-dbcp
	1.4


	commons-pool
	commons-pool
	1.6

创建用户的数据库表tb_user

CREATE TABLE `tb_user` (
  `id` bigint NOT NULL AUTO_INCREMENT COMMENT '自增主键',
  `name` varchar(255) NOT NULL DEFAULT '' COMMENT '姓名',
  `age` int NOT NULL DEFAULT '-1' COMMENT '年龄',
  PRIMARY KEY (`id`),
  KEY `index_name` (`name`) USING BTREE
) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8 COMMENT='用户信息表';

创建用户的实体类User.java

@Data
public class User{
    private Long id;
    private String name;
    private Integer age;
}

创建User接口接实现类UserService.java和UserServiceImpl.java

@Transactional(propagation = Propagation.REQUIRED) // 配置事务传播机制
public interface UserService {
    void save(User user);
}

public class UserServiceImpl implements UserService {
    private JdbcTemplate jdbcTemplate;
    
    public UserServiceImpl(DataSource dataSource) {
        jdbcTemplate = new JdbcTemplate(dataSource);
    }

    @Override
    public void save(User user) {
        Object[] userInfo = new Object[]{user.getName(), user.getAge()};
        int[] types = new int[]{Types.VARCHAR, Types.INTEGER};
        jdbcTemplate.update("insert into tb_user(name, age) values(?, ?)", userInfo, types);
        // throw new RuntimeException("抛出异常！"); // 制造回滚现象
    }
}

添加事务配置及数据库配置

创建测试类TxTest.java

public class TxTest {
    public static void main(String[] args) {
        ApplicationContext context = new ClassPathXmlApplicationContext("oldbean.xml");
        UserService userService = (UserService) context.getBean("userTxService");
        User user = new User();
        user.setName("muse");
        user.setAge(10);
        userService.save(user);
    }
}

在上面的例子中，如果我们放开UserServiceImpl.save(...)方法中的RuntimeException异常，那么则会在执行过程中由于发生异常而导致整个事务的回滚操作。

二、事务自定义标签

2.1> 注册InfrastructureAdvisorAutoProxyCreator

当我们希望在Spring中开启事务的时候，我们需要在配置中增加，如下所示：

我们在Spring项目中搜索“annotation-driven”，可以发现与事务相关的处理类为TxNamespaceHandler，在该类中，注册了AnnotationDrivenBeanDefinitionParser解析器，代码如下所示：

在AnnotationDrivenBeanDefinitionParser类中我们需要关注的就是parse(...)方法，它负责执行BeanDefiniton的解析操作。这里会通过mode属性来确定是采用aspectj的方式进行解析还是采用AOP代理的方式进行解析，具体逻辑如下所示：

由于常用的就是采用AOP代理的方式进行解析操作，所以此处我们只需要关心AopAutoProxyConfigurer类的configureAutoProxyCreator(...)方法，在该方法中需要执行如下几步的操作：

【步骤1】注册InfrastructureAdvisorAutoProxyCreator类型的APC；
【步骤2】创建AnnotationTransactionAttributeSource类型的BeanDefinition；
【步骤3】创建TransactionInterceptor类型的BeanDefinition；
【步骤4】创建BeanFactoryTransactionAttributeSourceAdvisor类型的BeanDefinition；
【步骤5】将以上3种BeanDefinition聚合到CompositeComponentDefinition中；

在registerAutoProxyCreatorIfNecessary(...)方法中，我们试图将InfrastructureAdvisorAutoProxyCreator类型注册为APC（AutoProxyCreator），代码如下所示：

public static void registerAutoProxyCreatorIfNecessary(ParserContext parserContext, Element sourceElement) {
	/** 注册InfrastructureAdvisorAutoProxyCreator类型的APC */
	BeanDefinition beanDefinition = AopConfigUtils.registerAutoProxyCreatorIfNecessary(parserContext.getRegistry(), parserContext.extractSource(sourceElement));
	
    /** 为名字为"org.springframework.aop.config.internalAutoProxyCreator"的BeanDefinition设置属性proxyTargetClass和属性exposeProxy的值 */
	useClassProxyingIfNecessary(parserContext.getRegistry(), sourceElement);
    
	// 将名称为"org.springframework.aop.config.internalAutoProxyCreator"的beanDefinition执行组件注册
	registerComponentIfNecessary(beanDefinition, parserContext);
}

AopConfigUtils类的registerAutoProxyCreatorIfNecessary(...)方法，实际作用就是注册InfrastructureAdvisorAutoProxyCreator类型的APC，源码如下所示：

2.2> InfrastructureAdvisorAutoProxyCreator获得代理对象

在上面的内容中，我们可以发现将InfrastructureAdvisorAutoProxyCreator类注册为APC，那么为了方便我们更加容易的理解这个类，我们先来看一下它的类图，有哪些继承关系。

在上面的类图中，我们发现它实现了BeanPostProcessor和InstantiationAwareBeanPostProcessor这两个类，这两个类分别提供了针对初始化的前置处理&后置处理的方法以及针对实例化的前置处理&后置处理的方法。

下面我们来看一下AbstractAutoProxyCreator类的postProcessAfterInitialization(...)方法，该方法实现了代理包装的逻辑，请见下面所示：

在wrapIfNecessary(...)方法中，主要的业务逻辑总共有两步：

【步骤1】找出指定bean对应的增强器；
【步骤2】根据找出的增强器创建代理；

AbstractAdvisorAutoProxyCreator类的getAdvicesAndAdvisorsForBean(...)方法，有如下3个主要步骤：首先，获得所有的Advisor增强器；其次，寻找匹配的增强器；最后，对增强器进行排序；此处我们只针对前两个步骤进行解析，代码如下所示：

2.2.1> findCandidateAdvisors() 获得所有增强器

findCandidateAdvisors()方法有两个子类实现，如下所示：

调用了AnnotationAwareAspectJAutoProxyCreator类中的findCandidateAdvisors()方法

protected List findCandidateAdvisors() { 
    /** 步骤1：寻找在IOC中注册过的Advisor接口的实现类 */
	List advisors = super.findCandidateAdvisors(); // 调用了AbstractAdvisorAutoProxyCreator类中的findCandidateAdvisors()方法
	if (this.aspectJAdvisorsBuilder != null) 
        /** 步骤2：寻找在IOC中注册过的使用@Aspect注解的类 */
		advisors.addAll(this.aspectJAdvisorsBuilder.buildAspectJAdvisors());
	
	return advisors;
}

我们在SpringAOP源码解析时，解析过AnnotationAwareAspectJAutoProxyCreator类的这个方法实现，那么在本章Spring声明式事务中，我们需要解析的就是AbstractAdvisorAutoProxyCreator类的findCandidateAdvisors()方法了。源码如下所示：

protected List findCandidateAdvisors() {
	return this.advisorRetrievalHelper.findAdvisorBeans();
}

在findAdvisorBeans()方法中，才是真正获得所有Advisor增强器的处理逻辑，如下源码所示：

public List findAdvisorBeans() {
	String[] advisorNames = this.cachedAdvisorBeanNames;
	if (advisorNames == null) {
        /** 获取IOC中实现了Advisor接口的所有bean的beanName列表 */
		advisorNames = BeanFactoryUtils.beanNamesForTypeIncludingAncestors(this.beanFactory, Advisor.class, true, false);
		this.cachedAdvisorBeanNames = advisorNames; // eg: advisorNames="org.springframework.transaction.config.internalTransactionAdvisor"
	}
	if (advisorNames.length == 0) return new ArrayList();
    
	List advisors = new ArrayList();
	for (String name : advisorNames) {
		if (isEligibleBean(name)) {
			if (this.beanFactory.isCurrentlyInCreation(name))
				if (logger.isTraceEnabled()) logger.trace("Skipping currently created advisor '" + name + "'");
			else {
				try {
                    /** 通过beanName获得实例对象，并放入到advisors中 */
					advisors.add(this.beanFactory.getBean(name, Advisor.class)); // eg: BeanFactoryTransactionAttributeSourceAdvisor
				} catch (BeanCreationException ex) {...}
			}
		}
	}
	return advisors; // eg: advisors=[BeanFactoryTransactionAttributeSourceAdvisor]
}

在该方法中，大致执行了两个部分的操作：
【第1部分】如果缓存cachedAdvisorBeanNames中没有缓存任何Advisor名称，则获取IOC中实现了Advisor接口的所有bean的beanName列表；
【第2部分】如果beanName列表不为空，则通过beanFactory.getBean(name, Advisor.class)获得实例对象，然后保存到advisors中；

此处需要补充一点的就是，在IOC中，默认初始化了一个Advisor接口的实现类BeanFactoryTransactionAttributeSourceAdvisor，它的beanName就是"org.springframework.transaction.config.internalTransactionAdvisor"，那么这个bean初始化的地方就是我们前面介绍的AopAutoProxyConfigurer类中的configureAutoProxyCreator(...)方法，如下所示：

2.2.2> findAdvisorsThatCanApply(...) 寻找匹配的增强器

在2.2.1中，我们已经分析完获取所有增强器的方法findCandidateAdvisors()，那么本节我们将在获取的所有增强（candidateAdvisors）基础上，再去寻找匹配的增强器，即：findAdvisorsThatCanApply(...)方法，相关源码如下图所示：

在findAdvisorsThatCanApply(...)方法中，其主要功能是获得所有增强器candidateAdvisors中，适用于当前clazz的增强器列表。而由于针对引介增强和普通增强的处理是不同的， 所以采用分开处理的方式，请见下图所示：

那么，什么是引介增强呢？引介增强是一种特殊的增强。其它的增强是方法级别的增强，即：只能在方法前或方法后添加增强。而引介增强则不是添加到方法上的增强， 而是添加到类级别的增强，即：可以为目标类动态实现某个接口，或者动态添加某些方法。具体实现请见下图所示：

那么，在上面的findAdvisorsThatCanApply(...)方法源码中，我们可以发现，canApply(...)方法是其中很重要的判断方法，那么它内部主要做了什么操作呢？在其方法内部，依然根据引介增强和普通增强两种增强形式分别进行的判断，其中，如果是引介增强的话，则判断该增强是否可以应用在targetClass上，如果可以则返回true，否则返回false。那么，如果是普通增强，则需要再调用canApply(...)方法继续进行逻辑判断。根据上文介绍，我们知道advisor的类型为BeanFactoryTransactionAttributeSourceAdvisor，我们通过类图的集成关系可以看到，它是属于PointcutAdvisor接口类型的，如下所示：

既然BeanFactoryTransactionAttributeSourceAdvisor是属于PointcutAdvisor接口类型的，那么就会执行下图中红框处代码。相关源码请见下图所示：

在canApply(...)方法中，主要的逻辑是获得targetClass类（非代理类） 及 targetClass类的相关所有接口 中的所有方法去匹配，是否满足对targetClass类的增强，如果找到了，则返回false；如果找不到，则返回true；相关源码，请见下图所示：

a> pc.getClassFilter().matches(targetClass) 判断类是否符合候选类

这里的pc.getClassFilter()获得的是TransactionAttributeSourcePointcut类，所以我们来看一下这个类中的matchs(Class clazz)方法，该方法的逻辑也比较简单，首先，判断入参clazz如果是实现了TransactionProxy、TransactionManager或PersistenceExceptionTranslator这三个任意1个接口，则直接返回false；否则，再试图获得TransactionAttributeSource实例对象，此处获得的是AnnotationTransactionAttributeSource类型的实例对象，如果获得不到tas，则返回true；如果获得到了tas，则调用其tas.isCandidateClass(...)方法执行进一步的判断逻辑，代码如下所示：

在isCandidateClass(...)方法中，用于判断入参的targetClass是否是候选类，即：确定给定的类是否是携带指定注释的候选类。此处的核心方法parser.isCandidateClass(targetClass)内部调用的就是AnnotationUtils.isCandidateClass(...)，此方法逻辑比较简单，此处不在赘述了。

// eg: targetClass=class com.muse.springbootdemo.tx.UserServiceImpl
/** 确定给定的类是否是携带指定注释的候选类(在类型、方法或字段级别)。 */
@Override
public boolean isCandidateClass(Class targetClass) {
	// eg: annotationParsers=[SpringTransactionAnnotationParser@2777, JtaTransactionAnnotationParser@2778]
	for (TransactionAnnotationParser parser : this.annotationParsers)
        /** isCandidateClass方法逻辑很简单，此处就不再赘述了 */
		if (parser.isCandidateClass(targetClass)) // eg：true
			return true;
	return false;
}

b> methodMatcher.matches(method, targetClass)判断是否匹配

那么，判断是否匹配是通过matches(...)方法来确定的，那么我们就来分析一下TransactionAttributeSourcePointcut类的该方法的处理逻辑，请见如下源码所示：

public boolean matches(Method method, Class targetClass) {
	TransactionAttributeSource tas = getTransactionAttributeSource();
   	return (tas == null || tas.getTransactionAttribute(method, targetClass) != null); // 进行匹配操作
}

通过getTransactionAttributeSource()方法我们会获得AnnotationTransactionAttributeSource类型的实例对象，由于tas的类型为AnnotationTransactionAttributeSource类，该类的getTransactionAttribute(...)方法是由AbstractFallbackTransactionAttributeSource类实现的，在该方法中，首先会试图从缓存attributeCache中获得TransactionAttribute实例对象，如果有缓存，则返回即可；如果该缓存为空，则需要通过computeTransactionAttribute(method, targetClass)方法来获取TransactionAttribute实例对象。源码如下所示：

在上面的分析中，我们已经知道了如果缓存中没有缓存TransactionAttribute实例对象的话，则需要通过调用computeTransactionAttribute(method, targetClass)方法来获取，那么下面我们就来分析这个方法。在这个方法中，主要的逻辑如下所示：

【步骤1】查看specificMethod的方法上是否存在声明式事务的注解，如果有则获取返回
【步骤2】查看specificMethod的类上是否存在声明式事务的注解，如果有则获取返回
【步骤3】查看method的方法上是否存在声明式事务的注解，如果有则获取返回
【步骤4】查看method的类上是否存在声明式事务的注解，如果有则获取返回

那么，在方法维度上查找就通过调用findTransactionAttribute(Method method)方法实现，在类的维度上查找就通过调用findTransactionAttribute(Class clazz)来实现。请见下图所示：

但是无论入参是Method实例还是Class，最终调用的都是determineTransactionAttribute(AnnotatedElement element)方法，所以我们将视野聚焦到这个方法上。在这个方法中，就是用过事务注解解析器（TransactionAnnotationParser）调用parseTransactionAnnotation(AnnotatedElement element)方法来执行解析操作，请见如下红框所示：

那么，针对事务注解解析器TransactionAnnotationParser，Spring默认有3个实现类，分别是针对Spring、JTA和EJB的，具体实现类请见下图所示：

那么，同样他们分别针对的注解为 @TransactionAttriubte 和 @Transactional 进行解析，当发现类或者方法上存在这类事务注解时，则返回解析后的TransactionAttribute实例对象。此处我们以 SpringTransactionAnnotationParser 为例，看一下parseTransactionAnnotation(...)方法是如何处理的。在该方法中主要做的工作就是解析事务注解中的配置信息，然后存储到rbta实例对象中。

protected TransactionAttribute parseTransactionAnnotation(AnnotationAttributes attributes) {
	RuleBasedTransactionAttribute rbta = new RuleBasedTransactionAttribute();
	// 解析propagation属性并赋值
	Propagation propagation = attributes.getEnum("propagation");
	rbta.setPropagationBehavior(propagation.value());

	// 解析isolation属性并赋值
	Isolation isolation = attributes.getEnum("isolation");
	rbta.setIsolationLevel(isolation.value());

	// 解析timeout & timeoutString属性并赋值
	rbta.setTimeout(attributes.getNumber("timeout").intValue());
	String timeoutString = attributes.getString("timeoutString");
	Assert.isTrue(!StringUtils.hasText(timeoutString) || rbta.getTimeout() < 0, "Specify 'timeout' or 'timeoutString', not both");
	rbta.setTimeoutString(timeoutString);

	// 解析readOnly & value & label属性并赋值
	rbta.setReadOnly(attributes.getBoolean("readOnly"));
	rbta.setQualifier(attributes.getString("value"));
	rbta.setLabels(Arrays.asList(attributes.getStringArray("label")));
	List rollbackRules = new ArrayList();
	for (Class rbRule : attributes.getClassArray("rollbackFor"))
		rollbackRules.add(new RollbackRuleAttribute(rbRule));
	for (String rbRule : attributes.getStringArray("rollbackForClassName"))
		rollbackRules.add(new RollbackRuleAttribute(rbRule));
	for (Class rbRule : attributes.getClassArray("noRollbackFor"))
		rollbackRules.add(new NoRollbackRuleAttribute(rbRule));
	for (String rbRule : attributes.getStringArray("noRollbackForClassName"))
		rollbackRules.add(new NoRollbackRuleAttribute(rbRule));

	// 解析rollbackFor & rollbackForClassName & noRollbackFor & noRollbackForClassName 属性并赋值
	rbta.setRollbackRules(rollbackRules);
	return rbta;
}

介绍完findTransactionAttribute(...)方法后，我们再来补充介绍一下computeTransactionAttribute(method, targetClass)方法中使用的ClassUtils.isUserLevelMethod(method) 方法，该方法的作用是判断给定的方法method，是不是用户自己声明的或者指向用户声明的方法。代码如下所示：

Method类中的isSynthetic()方法的作用是用于判断此方法是否是合成方法，如果是合成方法，则返回 true；否则返回 false。下面我们创建一个测试类SyntheticTest类，来看一下标准的User方法中，都是不是合成方法。从结果中我们可以看到4个方法的isSynthetic()都是false，即：都不是合成方法。请见如下代码所示：

那么，什么才是合成方法呢？ 我们在main方法中添加两个操作，创建User以及为age赋值，因为age是私有private的，但是外部程序要去调用，所以编译器做了这个工作。而增加的这个方法是JVM动态增加的，并不属于User类本身，那么该方法就是合成方法（下图中黄框中的输出）。请见如下代码所示：

三、事务增强器

在AopAutoProxyConfigurer类的configureAutoProxyCreator(...)方法中，我们创建一个TransactionInterceptor类型的RootBeanDefinition。那么TransactionInterceptor其实支撑着整个事务功能的架构，这个章节，我们就来好好分析一下这个类，通过如下类图，我们可以发现，它实现了MethodInterceptor接口，而这个接口只有一个invoke(...)方法，那么我们就可以从该方法作为切入点，了解一下其具体的实现过程：

在TransactionInterceptor类的invoke(invocation)方法中，我们可以看到关键的处理方法是invokeWithinTransaction(...)，其实也就是这个方法，包含了我们事务处理的最核心的处理流程：

public Object invoke(MethodInvocation invocation) throws Throwable {
	Class targetClass = (invocation.getThis() != null ?  
                            AopUtils.getTargetClass(invocation.getThis()) : null);
    return invokeWithinTransaction(invocation.getMethod(), targetClass, new CoroutinesInvocationCallback() {
		public Object proceedWithInvocation() throws Throwable {
			return invocation.proceed(); // 执行目标方法
		}
		public Object getTarget() {
			return invocation.getThis(); // 获得目标对象
		}
		public Object[] getArguments() {
			return invocation.getArguments(); // 获得目标方法入参
		}
	});
}

在TransactionAspectSupport类的invokeWithinTransaction()方法中，代码量还是很大的，那么为了方便大家理解，我们在原有方法的基础上“隐藏”掉了并不常用的流程代码，只保留了声明式事务的处理代码，代码及注释如下所示：

对于声明式的事务处理主要有以下几个步骤：

【步骤1】获取事务的属性TransactionAttribute，对于事务处理来说，这是最基础的前置工作了，同时为后续的事务操作做好准备。
【步骤2】加载配置中配置的TransactionManager。
【步骤3】针对reactive进行特殊处理。
-------------对于声明式事务与编程式事务进行不同方式处理，此处只展示声明式事务的处理过程-------------
【步骤4】在目标方法执行前获取事务井收集事务信息TransactionInfo。
【步骤5】执行目标方法。
【步骤6】如果出现RuntimeException异常，则尝试事务回滚。
【步骤7】提交事务前，要清除事务信息TransactionInfo。
【步骤8】提交事务。

为了便于大家理解，我将上面的类和方法调用以图的方式进行展示，我们会针对步骤4、步骤6和步骤8这四个部分进行详细解析。请见如下所示：

3.1> createTransactionIfNecessary(...) 创建并收集事务信息

在介绍创建事务逻辑之前，我们先了解一下事务的传播机制，如下所示：

本小节要分析的内容就是上面中描述的【步骤4】在目标方法执行前获取事务井收集事务信息TransactionInfo，那么，让我们来看一下TransactionAspectSupport类的createTransactionIfNecessary(...)方法，在该方法中，主要做了3个步骤：

【步骤1】如果txAttr没有设置name属性，则将方法的唯一标识（joinpointIdentification）赋值给name属性；
【步骤2】获得事务状态TransactionStatus；
【步骤3】执行事务信息准备操作；

其中，关键的两个步骤就是【步骤2】tm.getTransaction(txAttr)和【步骤3】prepareTransactionInfo(...)这两个方法，分别是用来获得事务状态以及执行事务信息的准备操作的，那么，下面我们就针对这两个方法做深入的解析。源码如下所示：

为了便于大家理解，我画出了createTransactionIfNecessary(...)方法的时序图，从该图中可以清晰的看到该方法的调用流程：

3.1.1> getTransaction(...) 获得事务状态

在getTransaction(...)方法中，主要的任务就是获得事务状态TransactionState，在处理过程中，主要分为如下几个步骤：

【步骤1】通过DataSourceTransactionManager的doGetTransaction()方法来获得JDBC的事务实例；
【步骤2】如果当前线程已经存在事务，则进行嵌套事务处理。此处处理完毕之后，直接return返回，不继续向下执行；
【步骤3】对配置的事务超时时间进行验证，如果小于-1，则抛出异常；
【步骤4-1】如果配置的事务隔离级别是MANDATORY，则直接抛出异常（因为走到这个步骤，则说明步骤2不满足，当前线程无事务）；
【步骤4-2】如果配置的事务隔离级别是REQUIRED、REQUIRES_NEW、NESTED，则执行startTransaction(...)开启新的事务；
【步骤4-3】如果配置的事务隔离级别是其他，则执行prepareTransactionStatus(...)方法创建事务状态并且初始化事务同步；

相关代码及注释如下所示：

a> doGetTransaction 获得数据库事务实例

在doGetTransaction)()方法中，主要就是创建DataSourceTransactionObject实例对象，然后并对其进行赋值。其中，通过obtainDataSource()方法获得JDBC的数据库数据源DataSource，然后将其传入到getResource()方法中，试图获取conHolder，一般来说我们获取的conHolder是为null的。这个方法逻辑比较简单，代码和注释如下所示：

protected Object doGetTransaction() {
	DataSourceTransactionObject txObject = new DataSourceTransactionObject();
    /** 返回是否允许嵌套事务，默认为false */
	txObject.setSavepointAllowed(isNestedTransactionAllowed()); 
    
    /** 获得数据源DataSource，并由此试图获取ConnectionHolder实例对象 */
	ConnectionHolder conHolder = (ConnectionHolder) TransactionSynchronizationManager.getResource(obtainDataSource());
	txObject.setConnectionHolder(conHolder, false);
	return txObject;
}

我们可以从事务同步管理器中看到，因为事务与当前线程息息相关，所以事务相关的重要属性都被保存到了ThreadLocal中去了，

为了后续使用事务同步管理器（TransactionSynchronizationManager）而做准备，即：初始化事务所需参数，包括：是否活跃、隔离级别、是否只读、名称、激活事务同步。代码如下所示：

/** 根据给定的参数创建一个新的事务状态实例对象（TransactionStatus），与此同时，针对事务同步器进行初始化 */
protected final DefaultTransactionStatus prepareTransactionStatus(TransactionDefinition definition,
																  @Nullable Object transaction,
																  boolean newTransaction,
																  boolean newSynchronization,
																  boolean debug,
																  @Nullable Object suspendedResources) {
	// 创建默认事务状态（DefaultTransactionStatus）实例对象
	DefaultTransactionStatus status = newTransactionStatus(definition, transaction, newTransaction, 
                                                           newSynchronization, debug, suspendedResources);
	
    // 为了后续使用事务同步管理器（TransactionSynchronizationManager）而做准备
	prepareSynchronization(status, definition);
    
	return status;
}

/** 为了后续使用事务同步管理器（TransactionSynchronizationManager）而做准备，即：初始化所需参数 */
protected void prepareSynchronization(DefaultTransactionStatus status, TransactionDefinition definition) {
	// 如果打开了新的事务同步
	if (status.isNewSynchronization()) {
		Integer level = definition.getIsolationLevel() != ISOLATION_DEFAULT ? definition.getIsolationLevel() : null;
        // 配置当前事务是否是【活跃的】
		TransactionSynchronizationManager.setActualTransactionActive(status.hasTransaction()); 
        // 配置当前事务的【隔离级别】
		TransactionSynchronizationManager.setCurrentTransactionIsolationLevel(level); 
        // 配置当前事务是否是【只读的】
		TransactionSynchronizationManager.setCurrentTransactionReadOnly(definition.isReadOnly()); 
        // 配置当前事务的【名称】
		TransactionSynchronizationManager.setCurrentTransactionName(definition.getName()); 
        // 激活并初始化【事务同步】
		TransactionSynchronizationManager.initSynchronization(); 
	}
}

b> handleExistingTransaction(...) 针对已存在事务进行处理

当发现当前线程中已经存在事务，那么则会执行handleExistingTransaction(...)方法，在该方法内部，主要是针对如下4种事务的传播机制进行处理：

【NEVER】无事务执行，如果当前有事务则抛出异常；
【NOT_SUPPORTED】无事务执行，如果当前事务存在，把当前事务挂起；
【REQUIRES_NEW】新建一个新事务；如果当前事务存在，把当前事务挂起；
【NESTED】嵌套事务，如果当前事务存在，那么在嵌套的事务中执行。如果当前事务不存在，则表现跟REQUIRED一样；

那么在该方法中，主要有3处重要的代码逻辑，suspend(...)用于对当前事务进行挂起操作；startTransaction(...)用于开启新的事务；这两个方法的解析，我们会在单独拉出来c和d两个部分来着重介绍。那么，还有一个方法是prepareTransactionStatus(...)，该方法我们稍后就先来介绍一下。如下是handleExistingTransaction(...)方法的源码及注释：

在prepareTransactionStatus(...)方法中，主要做了两件事：其一，创建事务状态实例对象（TransactionStatus）。其二，为了后续使用事务同步管理器（TransactionSynchronizationManager）而做准备，即：为TransactionSynchronizationManager初始化所需参数。

protected final DefaultTransactionStatus prepareTransactionStatus(TransactionDefinition definition,
																  @Nullable Object transaction,
																  boolean newTransaction,
																  boolean newSynchronization,
																  boolean debug,
																  @Nullable Object suspendedResources) {
	// 创建默认事务状态（DefaultTransactionStatus）实例对象
	DefaultTransactionStatus status = newTransactionStatus(definition, transaction, newTransaction,
                                         newSynchronization, debug, suspendedResources);
    
	/** 为了后续使用事务同步管理器（TransactionSynchronizationManager）而做准备 */
	prepareSynchronization(status, definition);
    
	return status;
}

/**
 * 为了后续使用事务同步管理器（TransactionSynchronizationManager）而做准备，即：初始化所需参数
 */
protected void prepareSynchronization(DefaultTransactionStatus status, TransactionDefinition definition) {
	// 如果打开了新的事务同步
	if (status.isNewSynchronization()) {
		Integer level = definition.getIsolationLevel() != ISOLATION_DEFAULT ? 
            								 definition.getIsolationLevel() : null;
        // 配置当前事务是否是【活跃】的
		TransactionSynchronizationManager.setActualTransactionActive(status.hasTransaction()); 
        // 配置当前事务的【隔离级别】
		TransactionSynchronizationManager.setCurrentTransactionIsolationLevel(level);
        // 配置当前事务是否是【只读】的
		TransactionSynchronizationManager.setCurrentTransactionReadOnly(definition.isReadOnly()); 
        // 配置当前事务的【名称】
		TransactionSynchronizationManager.setCurrentTransactionName(definition.getName()); 
        // 激活并初始化【事务同步】
		TransactionSynchronizationManager.initSynchronization();
	}
}

c> suspend() 挂起事务

suspend()的主要任务是：挂起给定的事务。首先暂停事务同步，然后委托给doSuspend(transaction)模板方法。其方法内部，主要执行如下3个模块逻辑：

【逻辑1】如果当前线程的事务同步处于活跃状态，则将所有的事务同步都停用，并且试图挂起给定的事务。然后，创建SuspendedResourcesHolder对象，将事务名称、只读状态、隔离级别和活跃状态缓存进去。
【逻辑2】当前线程的事务同步处于非活跃状态并且入参事务不为空，则挂起给定的事务；
【逻辑3】否则，返回null；

protected final SuspendedResourcesHolder suspend(@Nullable Object transaction) throws TransactionException {
	/** 当前线程的事务同步处于活动状态 */
	if (TransactionSynchronizationManager.isSynchronizationActive()) {
    	// 将所有的事务同步都停用掉
		List suspendedSynchronizations = doSuspendSynchronization();
		try {
			Object suspendedResources = null;
			if (transaction != null)
				suspendedResources = doSuspend(transaction); // 挂起给定的事务 DataSourceTransactionManager
			
            // 获得当前事务名称（name），并将当前事务名称设置为null
			String name = TransactionSynchronizationManager.getCurrentTransactionName();
			TransactionSynchronizationManager.setCurrentTransactionName(null);
			
            // 获得当前事务的只读状态（readOnly），并将当前事务的只读状态设置为false
			boolean readOnly = TransactionSynchronizationManager.isCurrentTransactionReadOnly();
			TransactionSynchronizationManager.setCurrentTransactionReadOnly(false);
			
            // 获得当前事务的隔离级别（isolationLevel），并将当前事务的隔离级别设置为null
			Integer isolationLevel = TransactionSynchronizationManager.getCurrentTransactionIsolationLevel();
			TransactionSynchronizationManager.setCurrentTransactionIsolationLevel(null);
			
            // 获得当前事务活跃状态（wasActive），并将当前事务的活跃状态设置为false
			boolean wasActive = TransactionSynchronizationManager.isActualTransactionActive();
			TransactionSynchronizationManager.setActualTransactionActive(false);
			
            // 将以上获取到的事务信息暂存到SuspendedResourcesHolder实例对象中
			return new SuspendedResourcesHolder(suspendedResources, suspendedSynchronizations, name, 
                                                readOnly, isolationLevel, wasActive);
		}
		catch (RuntimeException | Error ex) {
			doResumeSynchronization(suspendedSynchronizations);
			throw ex;
		}
	}

	/** 当前线程的事务同步处于非活动状态 并且 事务不为空 */
	else if (transaction != null) {
		Object suspendedResources = doSuspend(transaction); // 挂起给定的事务 DataSourceTransactionManager
		return new SuspendedResourcesHolder(suspendedResources);
	}
        
	/** 当前线程的事务同步处于非活动状态 并且 事务为空 */
	else return null;
}

/** 暂停当前线程的所有同步并停用事务同步 */
private List doSuspendSynchronization() {
	// 获得所有的事务同步器
	List suspendedSynchronizations = TransactionSynchronizationManager.
        getSynchronizations();
    
	for (TransactionSynchronization synchronization : suspendedSynchronizations)
		synchronization.suspend(); // 执行挂起操作
    
	TransactionSynchronizationManager.clearSynchronization(); // 清除时间同步器
	return suspendedSynchronizations;
}

通过getSynchronizations()方法来获得事务同步（TransactionSynchronization）集合，通过下面源码大家可以看到，这些信息都是保存在synchronizations中的：

public static List getSynchronizations() throws IllegalStateException {
	Set synchs = synchronizations.get(); // 从synchronizations中获得事务同步集合
	if (synchs == null) throw new IllegalStateException("Transaction synchronization is not active");
	if (synchs.isEmpty()) return Collections.emptyList();
	else {
		List sortedSynchs = new ArrayList(synchs);
		OrderComparator.sort(sortedSynchs);
		return Collections.unmodifiableList(sortedSynchs);
	}
}

d> startTransaction(...) 开启新事物

该方法的作用是在当前的线程上开启一个新的事务，方面里面除了创建一个DefaultTransactionStatus实例对象后，关键的两个方法就是doBegin(...)和prepareSynchronization(...)，而prepareSynchronization方法我们刚刚已经在上面讲解suspend(...)挂起事务的时候讲解过了，那么我们此处只需要讲解doBegin(...)方法即可：

private TransactionStatus startTransaction(TransactionDefinition definition, Object transaction,
		boolean debugEnabled, @Nullable SuspendedResourcesHolder suspendedResources) {
	boolean newSynchronization = (getTransactionSynchronization() != SYNCHRONIZATION_NEVER);

    // 创建DefaultTransactionStatus实例对象
	DefaultTransactionStatus status = newTransactionStatus(definition, transaction, true, newSynchronization,
			debugEnabled, suspendedResources);
    
	/** 构造transaction，包括设置ConnectionHolder、隔离级别、timeout如果是新连接，绑定到当前线程 */
	doBegin(transaction, definition); // eg: DataSourceTransactionManager
    
	/** 新同步事务的设置，针对于当前线程的设置（这个方法在c部分解析过） */
	prepareSynchronization(status, definition);
    
	return status;
}

在doBegin(...)方法中，首先从数据库中获得了数据库链接Connection，然后设置隔离级别和是否只读，然后关闭了自动提交配置，交由Spring框架来控制事务提交。最后，将当前获取到的连接绑定到当前线程即可。源码及注释如下所示：

3.2> completeTransactionAfterThrowing(...) 回滚处理

当事务中执行的逻辑出现异常的时候，就会在catch语句中执行completeTransactionAfterThrowing(...)方法，有一点需要注意的是，在该方法中并不是一定会执行回滚的，如果不满足某些条件，只会触发提交操作。代码如下所示：

那么哪些条件满足才能触发回滚操作呢？必须同时满足两个条件：

【条件1】txInfo.transactionAttribute 不为null；
【条件2】txInfo.transactionAttribute.rollbackOn(ex) 等于true；

其中，条件2的rollbackOn(ex)方法默认是在DefaultTransactionAttribute类中实现的，只有满足异常是RuntimeException或者Error的异常实现类，才会执行事务回滚，代码如下所示：

public boolean rollbackOn(Throwable ex) {
	return (ex instanceof RuntimeException || ex instanceof Error);
}

由于现在我们介绍的是回滚流程，所以我们假设是符合上面回滚触发条件的，那么会执行txInfo.getTransactionManager().rollback(txInfo.getTransactionStatus())这条语句，那么我们就将视野聚焦到AbstractPlatformTransactionManager类的rollback方法上。这个方法代码很少，也没什么逻辑，内部就是调用了processRollback(defStatus, false)来执行回滚操作，源码如下所示：

那么在processRollback(...)方法中，才是真正负责执行回滚操作的地方，在这个方法的前后，分别有负责触发回滚操作的前置操作（triggerBeforeCompletion）和后置操作（triggerAfterCompletion），本质上就是调用所有事务同步TransactionSynchronization实现类的beforeCompletion()和beforeCompletion()两个方法。

除了调用事务同步的方法之外，我们可以看到有3个判断，执行如下逻辑：

【判断1】如果有保存点（savepoint），则退回到保存点处，常用于嵌套事务。
【判断2】如果当前事务是一个独立的新事物，则直接执行回滚操作。
【判断3】如果当前事务不是独立的事务，则只进行标记，等到事务链执行完毕后再统一执行回滚操作。

最后，不要忘记，在finally中我们还会执行一些“收尾”工作，即：清空记录的资源并对挂起的资源进行恢复。processRollback方法的源码和注释请见如下所示：

3.2.1> rollbackToHeldSavepoint() 回滚及释放保存点

如果savepoint存在的话，那么可以通过调用rollbackToHeldSavepoint()方法来实现回滚到为事务保存的保存点，然后立即释放保存点操作，如下的红框就是这两个操作所涉及的代码部分，请见下图所示：

由于我们是使用JDBC方式进行数据库连接的，所以上面的getSavepointManager()返回的就是JdbcTransactionObjectSupport实例对象，如下就是该类中针对“回滚到保存点”和“释放保存点”的详细处理代码，从源码中可以看到，这两个操作最终还是需要借由Connection类的rollback(savepoint)和releaseSavepoint(savepoint)来实现回滚到保存点和释放保存点操作的。相关源码如下所示：

/** 回滚到保存点 */
public void rollbackToSavepoint(Object savepoint) throws TransactionException {
	ConnectionHolder conHolder = getConnectionHolderForSavepoint();
	try {
		// 调用Connection的rollback(savepoint)方法执行回滚
		conHolder.getConnection().rollback((Savepoint) savepoint); 
        
   		// 将rollbackOnly设置为false
		conHolder.resetRollbackOnly(); 
	}
	catch (Throwable ex) {throw new TransactionSystemException(...);}
}

/** 释放保存点 */
public void releaseSavepoint(Object savepoint) throws TransactionException {
	ConnectionHolder conHolder = getConnectionHolderForSavepoint();
	try {
		// 调用Connection的releaseSavepoint(savepoint)方法释放保存点
		conHolder.getConnection().releaseSavepoint((Savepoint) savepoint);
	}
	catch (Throwable ex) {logger.debug(...);}
}

3.2.2> doRollback(status) 回滚操作

在第二个if判断中，我们会执行回滚操作，此处调用的是DataSourceTransactionManager类的doRollback(...)方法，该方法非常简单，核心就是通过调用Connection的rollback()方法进行的回滚操作，代码如下所示：

protected void doRollback(DefaultTransactionStatus status) {
	DataSourceTransactionObject txObject = (DataSourceTransactionObject) status.getTransaction();
	Connection con = txObject.getConnectionHolder().getConnection();
	try {
		con.rollback(); // 回滚操作
	}
	catch (SQLException ex) {throw translateException("JDBC rollback", ex);}
}

3.2.3> cleanupAfterCompletion(status) 清空记录的资源并对挂起的资源进行恢复

当通过processRollback方法执行完回滚操作后，无论成功与否，都会执行finally中的cleanupAfterCompletion(status)方法，可以通过这个方法来执行一些“收尾”的工作，代码如下所示：

首先，判断如果当前事务是新的同步状态（status.isNewSynchronization()），需要调用clear() 方法将绑定到当前线程的事务信息清除，该方法很简单，就是执行ThreadLocal实例对象的remove()方法，代码如下所示：

public static void clear() {
	synchronizations.remove();
	currentTransactionName.remove();
	currentTransactionReadOnly.remove();
	currentTransactionIsolationLevel.remove();
	actualTransactionActive.remove();
}

其次，判断如果是新事务（status.isNewTransaction()），则需要调用doCleanupAfterCompletion(...) 方法来做些清除资源的工作，该方法的逻辑比较容易理解，我们直接来看源码和注释即可，请见下面所示：

protected void doCleanupAfterCompletion(Object transaction) {
	DataSourceTransactionObject txObject = (DataSourceTransactionObject) transaction;
	// 将数据库连接从当前线程中解除绑定
	if (txObject.isNewConnectionHolder())
		TransactionSynchronizationManager.unbindResource(obtainDataSource());

	// 重置链接
	Connection con = txObject.getConnectionHolder().getConnection();

	try {
		if (txObject.isMustRestoreAutoCommit()) con.setAutoCommit(true); // 恢复自动提交
        
		// 重置数据库链接
		DataSourceUtils.resetConnectionAfterTransaction(con, txObject.getPreviousIsolationLevel(), txObject.isReadOnly());
	}
	catch (Throwable ex) {logger.debug("Could not reset JDBC Connection after transaction", ex);}
	
	// 如果当前事务是独立的新创建的事务，则在事务完成时释放数据库连接
	if (txObject.isNewConnectionHolder())
		DataSourceUtils.releaseConnection(con, this.dataSource);
	
	txObject.getConnectionHolder().clear();
}

最后，判断如果在事务执行前有事务挂起（status.getSuspendedResources() != null），那么通过调用resume(...) 方法，将当前事务执行结束后需要将挂起事务恢复，该方法的逻辑同样比较容易理解，我们直接来看源码和注释即可，请见下面所示：

/**
 * 恢复给定的事务。首先委托给doResume模板方法，然后恢复事务同步。
 */
protected final void resume(Object transaction, SuspendedResourcesHolder resourcesHolder) throws TransactionException {
	if (resourcesHolder != null) {
		Object suspendedResources = resourcesHolder.suspendedResources;
		if (suspendedResources != null)
			doResume(transaction, suspendedResources); // 模版方法，具体行为下沉到子类去实现
		List suspendedSynchronizations = resourcesHolder.suspendedSynchronizations;
		if (suspendedSynchronizations != null) {
			TransactionSynchronizationManager.setActualTransactionActive(resourcesHolder.wasActive);
			TransactionSynchronizationManager.setCurrentTransactionIsolationLevel(resourcesHolder.isolationLevel);
			TransactionSynchronizationManager.setCurrentTransactionReadOnly(resourcesHolder.readOnly);
			TransactionSynchronizationManager.setCurrentTransactionName(resourcesHolder.name);
			doResumeSynchronization(suspendedSynchronizations);
		}
	}
}

3.3> commitTransactionAfterReturning(...) 事务提交

最后一部分，我们来了解一下事务提交逻辑，该部分是由commitTransactionAfterReturning(...)方法负责实现的，代码如下所示：

protected void commitTransactionAfterReturning(@Nullable TransactionInfo txInfo) {
	if (txInfo != null && txInfo.getTransactionStatus() != null)
        // 执行事务提交操作 AbstractPlatformTransactionManager
		txInfo.getTransactionManager().commit(txInfo.getTransactionStatus()); 
}

在commit方法的源码中，我们可以看到，并不仅仅执行了提交方法，而是如果满足一些条件，还会执行回滚操作，回滚操作由processRollback(...)方法负责处理，由于该方法的源码解析已经在3.2章节中介绍过了，那么此处就不赘述了。所以，从中我们可以看出，即使一个事务没有出现运行时异常，但是也不意味着事务一定会被提交。

还记得在3.2章节中，我们介绍过，如果某个事务是另一个事务的嵌入事务，但是，这些事务又不在Spring的管理范围内，或者无法设置保存点，那么Spring会通过设置回滚标识的方式来禁止提交（如下图所示）。首先当某个嵌入事务发生回滚的时候会设置回滚标识，而等到外部事务提交时， 一旦判断出当前事务被设置了回滚标识，则由外部事务来统一进行整体事务的回滚。所以，当事务没有被异常捕获的时候也并不意味着一定会执行提交的过程。

现在我们回过来，在继续分析事务提交的相关代码processCommit(...)，分析该方法源码可知，在提交过程中也并不是直接提交的，如果如何如下任意两种情况，则无法执行提交操作：

【情况1】当事务状态中有保存点信息（status.hasSavepoint()），则不会执行事务提交操作。
【情况2】当事务非新事务的时候，也不会去执行事务提交操作。

以上的这两个条件主要考虑的是内嵌事务的情况；对于内嵌事务，会在内嵌事务开始之前设置保存点，如果内嵌事务出现了异常，便会根据保存点信息进行回滚操作，但是，如果没有出现异常，内嵌事务也不会单独提交，而是根据事务流由最外层事务负责提交，所以如果当前存在保存点信息，那就说明本事务不是最外层事务，从而不用去执行保存操作，对于是否是新事务的判断也是基于此考虑。如果程序流通过了事务的层层把关，最后顺利地进入了提交流程，那么就可以通过Connection的commit()方法执行事务提交了。processCommit方法的代码及注释如下所示：

private void processCommit(DefaultTransactionStatus status) throws TransactionException {
	try {
		boolean beforeCompletionInvoked = false;
		try {
			boolean unexpectedRollback = false;
			prepareForCommit(status); // 空方法，无逻辑
			triggerBeforeCommit(status); // 触发所有TransactionSynchronization实例对象的beforeCommit方法
			triggerBeforeCompletion(status); // 触发所有TransactionSynchronization实例对象的beforeCompletion方法
			beforeCompletionInvoked = true;
            
			/** 如果有保存点savepoint */
			if (status.hasSavepoint()) {
				unexpectedRollback = status.isGlobalRollbackOnly();
				status.releaseHeldSavepoint(); // 消除掉保存点信息
			}
                
			/** 如果是新的事务 */
			else if (status.isNewTransaction()) {
				unexpectedRollback = status.isGlobalRollbackOnly();
				doCommit(status); // 如果是独立的事务则直接提交
			}
                
			/** 如果事务被全局标记为仅回滚，则返回是否尽早失败 */
			else if (isFailEarlyOnGlobalRollbackOnly()) unexpectedRollback = status.isGlobalRollbackOnly();
			if (unexpectedRollback) throw new UnexpectedRollbackException(...);
		}
		catch (UnexpectedRollbackException ex) {
			triggerAfterCompletion(status, TransactionSynchronization.STATUS_ROLLED_BACK);
			throw ex;
		}
		catch (TransactionException ex) {
			if (isRollbackOnCommitFailure()) doRollbackOnCommitException(status, ex);
			else triggerAfterCompletion(status, TransactionSynchronization.STATUS_UNKNOWN);
			throw ex;
		}
		catch (RuntimeException | Error ex) {
			if (!beforeCompletionInvoked) triggerBeforeCompletion(status);
			doRollbackOnCommitException(status, ex); // 事务提交出现了异常，那么则执行回滚操作
			throw ex;
		}
		try {
			triggerAfterCommit(status);
		}
		finally {
			triggerAfterCompletion(status, TransactionSynchronization.STATUS_COMMITTED);
		}
	}
	finally {
		cleanupAfterCompletion(status);
	}
}

为了便于大家理解，此处将processCommit中的部分“相似方法”提取出来作个统一的说明：

triggerBeforeCommit(status)：触发调用所有TransactionSynchronization实例对象的beforeCommit方法
triggerBeforeCompletion(status)：触发调用所有TransactionSynchronization实例对象的beforeCompletion方法
triggerAfterCommit(status)：触发调用所有TransactionSynchronization实例对象的afterCommit方法
triggerAfterCompletion(status, completionStatus)：触发调用所有TransactionSynchronization实例对象的afterCompletion方法
cleanupAfterCompletion(status) ：在3.2.3章节介绍了，此处略；

doCommit方法是负责事务提交工作的，该方法逻辑非常简单，就是通过Connection的commit()方法执行事务提交即可：

protected void doCommit(DefaultTransactionStatus status) {
	DataSourceTransactionObject txObject = (DataSourceTransactionObject) status.getTransaction();
	Connection con = txObject.getConnectionHolder().getConnection();
	try {
		con.commit(); // 提交事务
	}
	catch (SQLException ex) {throw translateException("JDBC commit", ex);}
}

当提交发生了异常的时候，我们会通过doRollbackOnCommitException方法来实现回滚操作，如果是新的事务，则执行回滚操作；如果是嵌套事务，并且是失败的，则进行回滚标记（设置rollbackOnly=true）。该方法的源码及注释如下所示：

private void doRollbackOnCommitException(DefaultTransactionStatus status, Throwable ex) throws TransactionException {
	try {
		if (status.isNewTransaction()) 
			doRollback(status); // 调用Connection的rollback()方法
            
		else if (status.hasTransaction() && isGlobalRollbackOnParticipationFailure()) 
			doSetRollbackOnly(status); // 设置rollbackOnly=true
	}
	catch (RuntimeException | Error rbex) {
		triggerAfterCompletion(status, TransactionSynchronization.STATUS_UNKNOWN);
		throw rbex;
	}
	triggerAfterCompletion(status, TransactionSynchronization.STATUS_ROLLED_BACK);
}

今天的文章内容就这些了：

写作不易，笔者几个小时甚至数天完成的一篇文章，只愿换来您几秒钟的 点赞 & 分享 。

更多技术干货，欢迎大家关注公众号“爪哇缪斯” ~ (^o^)/ ~ 「干货分享，每天更新」