使用SpringAop意外发现了神坑

　　今天使用aop时，发现一件很值得研究的事情。

　　我使用aop对一个service类的一个方法进行@After加强，该方法是开启了事务的，姑且叫它func()。

　　我也是看过aop源码的，我本以为func()的执行如果func()方法本身不报错，那么对它进行事务增强的Interceptor就会执行完毕，事务就应该提交才对。

　　但是我错了，我一共写了两个@After，第一个没有异常，但是第二个@After有异常。奇怪的事情发生了，事务并没有完成。

　　为什么呢？该问题姑且记下，看来源码看的还是不够啊。

　　由于项目中用的是CGLIB方式增强，这部分代码确实没看，只看过JDK方式的事务处理。问题也可能出在CGLIB上。

　　即使不是CGLIB使用JDK自带的动态代理也是不行的，也是会导致回滚的

　　================================================2020-11-12 16：00更新===========================

　　对于一个事务方法进行aop增强还是得慎重啊，因为不走完增强的逻辑，事务也不会提交的

　　而且如果增强部分抛了异常，还会影响事务的提交

@Override
//    @Transactional(propagation = Propagation.REQUIRED)
    public void batchAddIncreSubAndZkPersist(SubscribeObjSdk topData, List<DataMedia> originalInput,
            List<SubscribeObjSdk> retureSubList, KafkaGroup kafkaGroup) {
        
        processBatchAddIncreSub(topData, originalInput, retureSubList, kafkaGroup);
        logger.info("batchAddIncreSubAndZkPersist subscription no {} write db over", topData.getSubScriptionNo());
        
        Executor myExecutor = KafkaTopicAsyncThPoolSupplier.obtainThreadPool();
        
        CompletableFuture.supplyAsync(() -> {
            
          SubInfoService subInfoService = SpringContextUtils.getBean("subInfoService", SubInfoService.class);
            

 源代码是我有对这个方法 batchAddIncreSubAndZkPersist的增强，比如

@After(value="execution(* com.suning.rdrs.admin.service.impl.TaskServiceImpl.batchAddIncreSubAndZkPersist(..)) && args(a,b,c,d)")
    public void processCopyTaskTopicRelation(SubscribeObjSdk a, List<DataMedia> b,
            List<SubscribeObjSdk> c, KafkaGroup d) throws InterruptedException, ExecutionException {
        
        if (Objects.equals(a.getSubscribeType(), StringConstant.DI_WHOLESCHEMA_TYPE)) {
            
            SubscribeObjSdk subscribeSdk = c.get(0);
            DataMedia dataMedia = b.get(0);
            String dataCenter = dataMedia.getDataCenter();
            String ldc = propGetter.getRegularLdc(dataCenter);
            

现在发现的现象是 由于 写数据库的部分在 processBatchAddIncreSub 中，由于增强方法 processCopyTaskTopicRelation 会执行很长时间 ，这样 

CompletableFuture.supplyAsync(() -> {
            
          SubInfoService subInfoService = SpringContextUtils.getBean("subInfoService", SubInfoService.class);

如果上面的代码里有对数据的读取操作是读不到的，因为增强部分没有执行完，事务还没有提交。这就会导致逻辑出现问题

开始源码分析

　　spring的事务也是通过aop做的，事务增强的advisor是TransactionInterceptor，它也没什么特别的，跟用户自己的写的advisor都是一回事，如果我们对一个有事务的方法进行aop增强，请看下面的代码段

　　JdkDynamicAopProxy.invoke
　　List<Object> chain = this.advised.getInterceptorsAndDynamicInterceptionAdvice(method, targetClass);//所有advisor都会在这里被拿到

            // Check whether we have any advice. If we don't, we can fallback on direct
            // reflective invocation of the target, and avoid creating a MethodInvocation.
            if (chain.isEmpty()) {
                // We can skip creating a MethodInvocation: just invoke the target directly
                // Note that the final invoker must be an InvokerInterceptor so we know it does
                // nothing but a reflective operation on the target, and no hot swapping or fancy proxying.
                Object[] argsToUse = AopProxyUtils.adaptArgumentsIfNecessary(method, args);
                retVal = AopUtils.invokeJoinpointUsingReflection(target, method, argsToUse);
            }
            else {
                // We need to create a method invocation...
                invocation = new ReflectiveMethodInvocation(proxy, target, method, args, targetClass, chain);//把所有的advisor构造成一个ReflectiveMethodInvocation
                // Proceed to the joinpoint through the interceptor chain.
                retVal = invocation.proceed();
            }

　　ReflectiveMethodInvocation
　　@Override
    public Object proceed() throws Throwable {
        //    We start with an index of -1 and increment early.
        if (this.currentInterceptorIndex == this.interceptorsAndDynamicMethodMatchers.size() - 1) {
            return invokeJoinpoint();
        }

        Object interceptorOrInterceptionAdvice =
                this.interceptorsAndDynamicMethodMatchers.get(++this.currentInterceptorIndex);
        if (interceptorOrInterceptionAdvice instanceof InterceptorAndDynamicMethodMatcher) {
            // Evaluate dynamic method matcher here: static part will already have
            // been evaluated and found to match.
            InterceptorAndDynamicMethodMatcher dm =
                    (InterceptorAndDynamicMethodMatcher) interceptorOrInterceptionAdvice;
            if (dm.methodMatcher.matches(this.method, this.targetClass, this.arguments)) {
                return dm.interceptor.invoke(this);
            }
            else {
                // Dynamic matching failed.
                // Skip this interceptor and invoke the next in the chain.
                return proceed();
            }
        }
        else {
            // It's an interceptor, so we just invoke it: The pointcut will have
            // been evaluated statically before this object was constructed.
            return ((MethodInterceptor) interceptorOrInterceptionAdvice).invoke(this);//事务TransactionInterceptor就在这里执行
        }
    }

　　TransactionInterceptor.invoke，上面的this就是入参 MethodInvocation invocation 

@Override
    public Object invoke(final MethodInvocation invocation) throws Throwable {
        // Work out the target class: may be {@code null}.
        // The TransactionAttributeSource should be passed the target class
        // as well as the method, which may be from an interface.
        Class<?> targetClass = (invocation.getThis() != null ? AopUtils.getTargetClass(invocation.getThis()) : null);

        // Adapt to TransactionAspectSupport's invokeWithinTransaction...
        return invokeWithinTransaction(invocation.getMethod(), targetClass, new InvocationCallback() {
            @Override
            public Object proceedWithInvocation() throws Throwable {
                return invocation.proceed();
            }
        });
    }

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

        // If the transaction attribute is null, the method is non-transactional.
        final TransactionAttribute txAttr = getTransactionAttributeSource().getTransactionAttribute(method, targetClass);
        final PlatformTransactionManager tm = determineTransactionManager(txAttr);
        final String joinpointIdentification = methodIdentification(method, targetClass, txAttr);

        if (txAttr == null || !(tm instanceof CallbackPreferringPlatformTransactionManager)) {
            // Standard transaction demarcation with getTransaction and commit/rollback calls.
            TransactionInfo txInfo = createTransactionIfNecessary(tm, txAttr, joinpointIdentification);
            Object retVal = null;
            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();//其实这里会把所有的advisor都执行一遍，所以嘞，如果我们写的aop有异常，当然会让事务回滚了
            }
            catch (Throwable ex) {