Spring AOP和事务的相关陷阱

朴灿烈づ我的快乐病毒、 2022-06-11 00:45 248阅读 0赞

# 1、前言 #

Spring AOP在使用过程中需要注意一些问题，也就是平时我们说的陷阱，这些陷阱的出现是由于Spring AOP的实现方式造成的。对于这些缺陷本人坚持的观点是：一是每一样技术都或多或少有它的局限性，很难称得上完美，只要掌握其实现原理，在使用时不要掉进陷阱就行，也就是进行规避；二是更进一步讲，我们应该接受这就是技术本身的特点，也说不上什么缺陷，它本身就在“那里”，只是我们要的结果是“这样”，而它表现的是“那样”，恰好不是我们想要的而已。

对于Spring AOP的陷阱，我总结了以下两个方面，现在分别进行介绍。

# 2、嵌套方法拦截失效 #

## 2.1 问题场景 ##

通过例子来讲解这样更好，首先加上注解配置：

<aop:aspectj-autoproxy/>

然后定义一个切面，代码如下：

![ContractedBlock.gif][] ![ExpandedBlockStart.gif][]

![复制代码][copycode.gif]

@Aspect
    @Component
    public class AnnotationAspectTest {
     
        @Pointcut("execution(* *.action(*))")
        public void action() {
        }
     
        @Pointcut("execution(* *.work(*))")
        public void work() {
        }
     
        @Pointcut("action() || work())")
        public void compositePointcut() {
        }
     
        //前置通知
        @Before("compositePointcut()")
        public void beforeAdvice() {
            System.out.println("before advice.................");
        }
     
        //后置通知
        @After("compositePointcut()")
        public void doAfter() {
            System.out.println("after advice..................");
        }
    }

![复制代码][copycode.gif]

测试代码：

![ContractedBlock.gif][] ![ExpandedBlockStart.gif][]

![复制代码][copycode.gif]

//定义接口
    public interface IPersonService {
        String action(String msg);
     
        String work(String msg);
    }
      
    //编写实现类
    @Service
    public class PersonServiceImpl implements IPersonService {
     
        public String action(String msg) {
            System.out.println("FooService, method doing.");
     
            this.work(msg);                                           // *** 代码 1 ***
     
            return "[" + msg + "]";
        }
     
        @Override
        public String work(String msg) {
            System.out.println("work: * " + msg + " *");
            return "* " + msg + " *";
        }
    }
      
    //单元测试
    @RunWith(SpringJUnit4ClassRunner.class)
    @ContextConfiguration(locations = {"classpath:applicationContext.xml"})
    public class FooServiceTest {
     
        @Autowired
        private IPersonService personService;
     
        @Test
        public void testAction() {
            personService.action("hello world.");
        }
    }

![复制代码][copycode.gif]

测试结果：

说明嵌套在action方法内部的work方法没有被进行切面增强，它没有被“切中”。

## 2.2 解决方案 ##

在实现类中，如果注释掉代码1，将代码1改为：

((IPersonService) AopContext.currentProxy()).work(msg);   // *** 代码 2 ***

并且在XML配置中加上expose-proxy="true"，变为：<aop:aspectj-autoproxy expose-proxy="true"/>

运行结果为：

嵌套在action方法内部的work方法被进行了切面增强，它被“切中”。

## 2.3 原因分析 ##

### 2.3.1 原理 ###

以上结果的出现与Spring AOP的实现原理息息相关，由于Spring AOP采用了动态代理实现AOP，在Spring容器中的bean（也就是目标对象）会被代理对象代替，代理对象里加入了我们需要的增强逻辑，当调用代理对象的方法时，目标对象的方法就会被拦截。而上文中问题出现的症结也就是在这里，为了进一步说明这个问题，用图片说明最好：

通过调用代理对象的action方法，在其内部会经过切面增强，然后方法被发射到目标对象，在目标对象上执行原有逻辑，如果在原有逻辑中嵌套调用了work方法，则此时work方法并没有被进行切面增强，因为此时它已经在目标对象内部。

而解决方案很好地说明了，将嵌套方法发射到代理对象，这样就完成了切面增强。

### 2.3.2 源代码分析 ###

接下来我们简单看一下源代码，Spring AOP的代码逻辑相当清晰：

![ContractedBlock.gif][] ![ExpandedBlockStart.gif][]

/**
     * Implementation of {
         @code InvocationHandler.invoke}.
     * <p>Callers will see exactly the exception thrown by the target,
     * unless a hook method throws an exception.
     */
    public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {
          ... ...
     
          Object retVal;
     
          //*** 代码3 ***
          if (this.advised.exposeProxy) {
             // Make invocation available if necessary.
             oldProxy = AopContext.setCurrentProxy(proxy);
             setProxyContext = true;
          }
     
          ... ...
     
          // Get the interception chain for this method.
          List<Object> chain = this.advised.getInterceptorsAndDynamicInterceptionAdvice(method, targetClass);
     
          // 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.
             retVal = AopUtils.invokeJoinpointUsingReflection(target, method, args);
          }
          else {
             // We need to create a method invocation...
             invocation = new ReflectiveMethodInvocation(proxy, target, method, args, targetClass, chain);
             // Proceed to the joinpoint through the interceptor chain.
             retVal = invocation.proceed();
          }
     
          ... ...
    }

在代码3处，如果配置了exposeProxy开关，则会将代理对象暴露在当前线程中，以供其它需要的地方使用。那么是怎么暴露的呢？答案很简单，通过使用静态的全局ThreadLocal变量就解决了问题。

# 3、Spring事务在多线程环境下失效 #

## 3.1 问题场景 ##

沿用上面的代码稍作修改，加上事务配置：

<bean id="transactionManager" class="org.springframework.jdbc.datasource.DataSourceTransactionManager">
     <property name="dataSource" ref="meilvDataSource"/>
    </bean>
    <tx:annotation-driven transaction-manager="transactionManager"/>

代码如下所示：

![ContractedBlock.gif][] ![ExpandedBlockStart.gif][]

![复制代码][copycode.gif]

@Service
    @Transactional(propagation = Propagation.REQUIRED, timeout = 10000000)
    public class PersonServiceImpl implements IPersonService {
     
        @Autowired
        IUserDAO userDAO;
     
        @Override
        public String action(final String msg) {
     
            new Thread(new Runnable() {
                @Override
                public void run() {
                    (getThis()).work(msg);
                }
            }).start();
     
            UserDO userDO = new UserDO();
            userDO.setName("lanlan");
            userDAO.insert(userDO);
     
            return "[" + msg + "]";
        }
     
        @Override
        public String work(String msg) {
            System.out.println("work: * " + msg + " *");
            UserDO userDO = new UserDO();
            userDO.setName("yanyan");
            userDAO.insert(userDO);
     
            throw new RuntimeException();
        }
     
        private IPersonService getThis() {
            try {
                return (IPersonService) AopContext.currentProxy();
            } catch (IllegalStateException e) {
                return this;
            }
        }
    }

![复制代码][copycode.gif]

结果：work方法中抛出异常，但是没有影响事务的回滚，说明事务在子线程中失效了。

## 3.2 解决方案 ##

只需要将多线程中的方法提出来，或者作为另一个Service类中的方法即可。

![ContractedBlock.gif][] ![ExpandedBlockStart.gif][]

![复制代码][copycode.gif]

@Service
    @Transactional(propagation = Propagation.REQUIRED, timeout = 10000000)
    public class PersonServiceImpl implements IPersonService {
     
        @Autowired
        IUserDAO userDAO;
     
        @Override
        public String action(final String msg) {
     
           (getThis()).work(msg);
     
            UserDO userDO = new UserDO();
            userDO.setName("lanlan");
            userDAO.insert(userDO);
     
            return "[" + msg + "]";
        }
     
        @Override
        public String work(String msg) {
            System.out.println("work: * " + msg + " *");
            UserDO userDO = new UserDO();
            userDO.setName("yanyan");
            userDAO.insert(userDO);
     
            throw new RuntimeException();
        }
     
        private IPersonService getThis() {
            try {
                return (IPersonService) AopContext.currentProxy();
            } catch (IllegalStateException e) {
                return this;
            }
        }
    }

![复制代码][copycode.gif]

上面只是一个简单的例子，用于进行问题说明。

a、如果去掉多线程，将方法放在同一个类里，Spring则会根据事务的传播配置参数，是否重新启用新的事务。

b、如果将方法独立出来放在新的类里，并且该方法也配置了事务，则会重新启用新的事务。

## 3.3 原因分析 ##

Spring的事务处理为了与数据访问解耦，它提供了一套处理数据资源的机制，而这个机制与上文中的原理相差无几，也是采用的ThreadLocal的方式。

在编程中，Service实例都是单例的无状态的，事务管理则需要加入事务控制的相关状态变量，使得Service实例不再是无状态线程安全的，解决这个问题的方式就是使用ThreadLocal。

通过使用ThreadLocal将数据源绑定在当前线程上，在当前线程的事务中，从设定的地方去取连接就会是同一个数据库连接，这样操作事务就会在同一个连接上进行。

如下图所示：

但是，ThreadLocal的特性是，绑定在当前线程中的变量不会自动传递到其它线程中（当然，InheritableThreadLocal可以在父子线程中间传递变量值，但是这需要特殊的使用场景），所以当开启子线程时，子线程并没有父线程的数据库连接资源。

对于上文提到的陷阱：如果另外开启线程，那么在新线程中将获取不到父线程的连接，事务要么失效，要么重新开启一个新的。

源代码如下：

![ContractedBlock.gif][] ![ExpandedBlockStart.gif][]

public abstract class DataSourceUtils {
     
       public static Connection getConnection(DataSource dataSource) throws CannotGetJdbcConnectionException {
          try {
             return doGetConnection(dataSource);
          }
          catch (SQLException ex) {
             throw new CannotGetJdbcConnectionException("Could not get JDBC Connection", ex);
          }
       }
        
       public static Connection doGetConnection(DataSource dataSource) throws SQLException {
           ConnectionHolder conHolder = (ConnectionHolder) TransactionSynchronizationManager.getResource(dataSource);
           if (conHolder != null && (conHolder.hasConnection() || conHolder.isSynchronizedWithTransaction())) {
              conHolder.requested();
              if (!conHolder.hasConnection()) {
                 logger.debug("Fetching resumed JDBC Connection from DataSource");
                 conHolder.setConnection(dataSource.getConnection());
              }
              return conHolder.getConnection();
           }
        
           Connection con = dataSource.getConnection();
     
           ......
     
           return con;
        }
    }
      
      
    public abstract class TransactionSynchronizationManager {
     
       private static final ThreadLocal<Map<Object, Object>> resources =
             new NamedThreadLocal<Map<Object, Object>>("Transactional resources");
     
       /**
        * Retrieve a resource for the given key that is bound to the current thread.
        * @param key the key to check (usually the resource factory)
        * @return a value bound to the current thread (usually the active
        * resource object), or {
         @code null} if none
        * @see ResourceTransactionManager#getResourceFactory()
        */
       public static Object getResource(Object key) {
          Object actualKey = TransactionSynchronizationUtils.unwrapResourceIfNecessary(key);
          Object value = doGetResource(actualKey);
          if (value != null && logger.isTraceEnabled()) {
             logger.trace("Retrieved value [" + value + "] for key [" + actualKey + "] bound to thread [" +
                   Thread.currentThread().getName() + "]");
          }
          return value;
       }
     
       /**
        * Actually check the value of the resource that is bound for the given key.
        */
       private static Object doGetResource(Object actualKey) {
          Map<Object, Object> map = resources.get();
          if (map == null) {
             return null;
          }
          Object value = map.get(actualKey);
          // Transparently remove ResourceHolder that was marked as void...
          if (value instanceof ResourceHolder && ((ResourceHolder) value).isVoid()) {
             map.remove(actualKey);
             // Remove entire ThreadLocal if empty...
             if (map.isEmpty()) {
                resources.remove();
             }
             value = null;
          }
          return value;
       }
    }

# 4、总结 #

本文总结了Spring AOP和事务的两个陷阱，在平时的实际开发中经常与遇到，只有深入了解了其中的原理，才会在工作中能够有效应对。

[ContractedBlock.gif]: http://images.cnblogs.com/OutliningIndicators/ContractedBlock.gif
[ExpandedBlockStart.gif]: /images/20220611/3aba856c992a4d099d0b69cb6d81d21e.png
[copycode.gif]: /images/20220611/3e67a1281c1e402f84f3ba0dc9ffc59f.png