彻底弄懂spring事务源码以及使用

一背景：先看如下代码，然后思考问题

@Service
public class MyService {

    public void doTest(){
        this.doTest2();
    }
    @Transactional
    public void doTest2(){
        this.doTest3();

    }

    @Transactional(timeout = 20)
    public void doTest3(){
        this.doTest4();
    }
    @Transactional(timeout = 30,propagation=Propagation.REQUIRED)
    public void doTest4(){
        System.out.println("ddddddddddddddddd");

    }
}

@Configuration
@ComponentScan("com.yang.xiao.hui.aop")
@EnableTransactionManagement
public class App {
    public static void main(String[] args) {

        ApplicationContext ctx = new AnnotationConfigApplicationContext(App.class);
        MyService service = ctx.getBean(MyService.class);
        service.doTest();
        service.doTest2();
    }
}

思考1：如果我接着调用doTest(）方法，事务会生效么？

思考2：如果我调用doTest2(),那么事务是以doTest2的为准，还是doTest3的为准,还是doTest4的为准

思考3：贴了@Transactional注解就一定要配置数据库么？

思考4： 事务的传播级和隔离级别怎么配置？

二 .源码分析：

我们贴了一个@Transactional，事务就生效，那么该方法肯定被拦截了，所以会存在一个特殊的方法拦截器，MethodInterceptor,我们唯一的入口就是在主启动类贴了一个@EnableTransactionManagement注解，那么我们就从这里入手，看该注解做了

啥？

 通过上图，可知道，一个简单的注解就向spring容器中注入了那么多的类，我们关注的类是ProxyTransactionManagementConfiguration

我们看看该类的源码：

 通过上图，我们找到了一个事务拦截器，看看它的继承体系：

 它就是一个方法拦截器，方法执行时会拦截目标方法，那么我们的事务操作肯定都是在这个拦截器的拦截方法里，debug调试该方法即可

 继续根进：

@Nullable
    protected Object invokeWithinTransaction(Method method, @Nullable Class<?> targetClass,
            final InvocationCallback invocation) throws Throwable {

        // If the transaction attribute is null, the method is non-transactional.
        TransactionAttributeSource tas = getTransactionAttributeSource(); //事务属性来源，啥意思呢？就是说哪些方法贴有事务注解，类似一个map将所有贴有事务注解的方法存了起来
        final TransactionAttribute txAttr = (tas != null ? tas.getTransactionAttribute(method, targetClass) : null);//通过指定的目标方法，去找到该方法贴的事务注解的信息，注解里面有很多参数的
        final PlatformTransactionManager tm = determineTransactionManager(txAttr); //通过事务注解配置的属性来决定使用什么样的事务管理器
        final String joinpointIdentification = methodIdentification(method, targetClass, txAttr);//给这个方法启个唯一标识

        if (txAttr == null || !(tm instanceof CallbackPreferringPlatformTransactionManager)) { //默认tm都是不属于CallbackPrefering....,所以会进入下面的逻辑
            // Standard transaction demarcation with getTransaction and commit/rollback calls.
            TransactionInfo txInfo = createTransactionIfNecessary(tm, txAttr, joinpointIdentification); //通过事务管理器，事务信息对象创建事务对象，在这一步将事务对象放到了ThreadLocal中

            Object retVal;
            try {
                // This is an around advice: Invoke the next interceptor in the chain.
                // This will normally result in a target object being invoked.
                retVal = invocation.proceedWithInvocation(); //开始执行目标方法
            }
            catch (Throwable ex) {
                // target invocation exception
                completeTransactionAfterThrowing(txInfo, ex);  //抛异常事务回滚
                throw ex;
            }
            finally {
                cleanupTransactionInfo(txInfo); //清空这次事务信息，也就是从ThreadLocal中移除
            }
            commitTransactionAfterReturning(txInfo); //如果没有抛异常就事务回滚
            return retVal;
        }

        else {
            final ThrowableHolder throwableHolder = new ThrowableHolder();  //另一个分支

            // It's a CallbackPreferringPlatformTransactionManager: pass a TransactionCallback in.
            try {
                Object result = ((CallbackPreferringPlatformTransactionManager) tm).execute(txAttr, status -> {
                    TransactionInfo txInfo = prepareTransactionInfo(tm, txAttr, joinpointIdentification, status);
                    try {
                        return invocation.proceedWithInvocation(); //执行目标方法
                    }
                    catch (Throwable ex) {
                        if (txAttr.rollbackOn(ex)) { //判断是否配置的异常，是就抛出去
                            // A RuntimeException: will lead to a rollback.
                            if (ex instanceof RuntimeException) {
                                throw (RuntimeException) ex;
                            }
                            else {
                                throw new ThrowableHolderException(ex);
                            }
                        }
                        else {
                            // A normal return value: will lead to a commit.
                            throwableHolder.throwable = ex;
                            return null;
                        }
                    }
                    finally {
                        cleanupTransactionInfo(txInfo);
                    }
                });

                // Check result state: It might indicate a Throwable to rethrow.
                if (throwableHolder.throwable != null) {
                    throw throwableHolder.throwable;
                }
                return result;
            }
            catch (ThrowableHolderException ex) {
                throw ex.getCause();
            }
            catch (TransactionSystemException ex2) {
                if (throwableHolder.throwable != null) {
                    logger.error("Application exception overridden by commit exception", throwableHolder.throwable);
                    ex2.initApplicationException(throwableHolder.throwable);
                }
                throw ex2;
            }
            catch (Throwable ex2) {
                if (throwableHolder.throwable != null) {
                    logger.error("Application exception overridden by commit exception", throwableHolder.throwable);
                }
                throw ex2;
            }
        }
    }

 上述方法非常清楚的展示了事务的执行原理：

 接着详细分析上面的每个流程：

  我先看看事务管理器接口的构成：该接口提供了事务提交方法，和事务的回滚方法

 因此，我们先分析最简单的事务回滚和事务提交方法：

1.completeTransactionAfterThrowing(txInfo, ex);事务回滚方法

 由源码知道，只有指定了哪些异常要回滚，事务才会回滚，否则事务就直接提交，但我们也没指定过，因此有必要看看txInfo.transactionAttribute.rollbackOn(ex)的逻辑

 

 默认没有配置指定异常，事务回滚也只会针对RuntimeException或者Error

 2. 接下来看看事务提交逻辑：commitTransactionAfterReturning(txInfo);

 由此看来，事务管理器是一个非常重要的接口，但他仅仅是个接口，具体事务怎么提交或者回滚，完全是由接口的实现类来决定，那么，我们就不一定需要是数据库，我们也可以针对redist,mogodb等来实现该接口，进

行对应的事务提交或者回滚，因此，开头提出的思考3：贴了@Transactional注解就一定要配置数据库么？答案就显而易见了

既然事务是由事务管理器来决定的，它是一个接口，那它是如何决定使用哪个事务管理器的呢？下面我们分析事务管理器的获取过程：

final PlatformTransactionManager tm = determineTransactionManager(txAttr);

@Nullable
    protected PlatformTransactionManager determineTransactionManager(@Nullable TransactionAttribute txAttr) {
        // Do not attempt to lookup tx manager if no tx attributes are set
        if (txAttr == null || this.beanFactory == null) {
            return getTransactionManager(); //获取默认的事务管理器，由于没有配置，所以取不到
        }

        String qualifier = txAttr.getQualifier(); //如果我们在事务注解上指定了事务管理器的beanName，就从spring容器中或者
        if (StringUtils.hasText(qualifier)) {
            return determineQualifiedTransactionManager(this.beanFactory, qualifier);
        }
        else if (StringUtils.hasText(this.transactionManagerBeanName)) {  //如果前面不满足，本类配置事务管理器的BeanName就以其为准
            return determineQualifiedTransactionManager(this.beanFactory, this.transactionManagerBeanName);
        }
        else {
            PlatformTransactionManager defaultTransactionManager = getTransactionManager(); //上面的都不满足，就获取默认事务管理器
            if (defaultTransactionManager == null) {
                defaultTransactionManager = this.transactionManagerCache.get(DEFAULT_TRANSACTION_MANAGER_KEY); //没有的话，就从缓存中获取
                if (defaultTransactionManager == null) {
                    defaultTransactionManager = this.beanFactory.getBean(PlatformTransactionManager.class); //缓存中没有的话，就直接从容器中获取PlatformTransactionManager
                    this.transactionManagerCache.putIfAbsent(
                            DEFAULT_TRANSACTION_MANAGER_KEY, defaultTransactionManager); //将获取到的事务管理器设置到缓存中
                }
            }
            return defaultTransactionManager;
        }
    }

上述的获取过程非常的简单：如果我们自己指定了事务管理器，就用我们自己的，没有指定就从spring容器获取默认的；这样我们是可以创建自己的事务管理器，然后配置给指定的事务：如

 

 最后看看我们配置的事务注解属性是如何被封装成对象的：先看看事务注解都有哪些属性：

public @interface Transactional {

    @AliasFor("transactionManager")
    String value() default ""; //指定事务管理器的BeanName

    @AliasFor("value")
    String transactionManager() default ""; //指定事务管理器的beanName

    Propagation propagation() default Propagation.REQUIRED; //事务的传播级别，面试时问spring事务的传播级别，答案就在这里了

    Isolation isolation() default Isolation.DEFAULT; //事务的隔离级别

    int timeout() default TransactionDefinition.TIMEOUT_DEFAULT; //事务的超时时间

    boolean readOnly() default false;

    Class<? extends Throwable>[] rollbackFor() default {}; //异常时，哪些异常需要回滚

    String[] rollbackForClassName() default {}; //异常时，哪些异常需要回滚
    
    Class<? extends Throwable>[] noRollbackFor() default {};//异常时，哪些异常不需要回滚

    String[] noRollbackForClassName() default {};//异常时，哪些异常不需要回滚

}

上述的属性最终会被封装成：TransactionAttribute，回到最初拦截的源码：

 一直跟进去后，可以看到：

 

 可以看到，很多属性是跟数据库有关的，事务的隔离级别，传播级别等，他们实现的事务管理器是DataSourceTransactionManager，有兴趣的可以了解该事务管理器的实现，就可以知道事务的传播级别原理了

三.问题解答：

 

 问题1：直接调用doTest方法，doTest方法没有事务，然后doTest方法调用doTest2,doTest2有事务，那么doTest2的事务能生效么？debug在方法拦截器里

 

 执行结果发现，debug走不到事务拦截器那里，看看控制台的打印：

 由此得出结论，同一个类中，非事务方法调用事务方法，会导致事务失效，原因如下：

service.doTest();虽然service是代理类，但真正执行doTest时，是代理类中的被代理对象调用的

 既然我们知道了，doTest2并不是被代理类service直接调用的，那么如果我们就是使用service直接调用不就可以了么？我们第一能想到的是作为参数传入，改造如下

 启动再次测试：

 由此看到，事务生效了，那还有没更好的方案呢，因为这样传感觉不方便，代码回滚到之前，在service.doTest() debug调试

 引出来2个问题：1.条件如何设置，AopContext存代理对象到哪里

 

 由此可知，设置到了ThreadLocal中了，那条件又是啥：exposeProxy，该属性在@EnableAspectJAutoProxy(exposeProxy = true)中，于是我们改造代码：

 

 至此：当一个类中非事务方法，调用事务方法时，不生效的解决方案有上面2种；

最后一个问题：

 多个事务方法直接的链式调用，到底以哪个事务为准，这里生效的前提是数据库的事务管理器，或者对事务传播级别做处理的事务管理器：这里就可以顺便了解下事务传播级别了

PROPAGATION_REQUIRED 如果存在一个事务，则支持当前事务。如果没有事务则开启一个新的事务。

PROPAGATION_SUPPORTS 如果存在一个事务，支持当前事务。如果没有事务，则非事务的执行。但是对于事务同步的事务管理器，PROPAGATION_SUPPORTS与不使用事务有少许不同。

PROPAGATION_MANDATORY 如果已经存在一个事务，支持当前事务。如果没有一个活动的事务，则抛出异常。

PROPAGATION_REQUIRES_NEW 总是开启一个新的事务。如果一个事务已经存在，则将这个存在的事务挂起。

PROPAGATION_NOT_SUPPORTED 总是非事务地执行，并挂起任何存在的事务。

PROPAGATION_NEVER 总是非事务地执行，如果存在一个活动事务，则抛出异常

PROPAGATION_NESTED如果一个活动的事务存在，则运行在一个嵌套的事务中. 如果没有活动事务, 则按TransactionDefinition.PROPAGATION_REQUIRED 属性执行

我们以默认的事务传播级别来解答：

PROPAGATION_REQUIRED 如果存在一个事务，则支持当前事务。如果没有事务则开启一个新的事务。例如doTest2()——》doTest3()，对于doTest3()来说，如果它配置的事务隔离级别是REQUIRED，那么doTest3就会以doTest2配置的事务来执行

PROPAGATION_MANDATORY 如果已经存在一个事务，支持当前事务。如果没有一个活动的事务，则抛出异常。例如doTest2()——》doTest3()，对于doTest3()来说，如果配置了该级别，doTest2配置了事务就使用，doTest2没有活动的事务就抛异常

其他的隔离级别以此类推。。。。。。。。。。。。。