Spring AOP和事务的相关陷阱
- 1、前言
- 2、嵌套方法拦截失效
- 2.1 问题场景
- 2.2 解决方案
- 2.3 原因分析
- 2.3.1 原理
- 2.3.2 源代码分析
- 3、Spring事务在多线程环境下失效
- 3.1 问题场景
- 3.2 解决方案
- 3.3 原因分析
- 4、总结
1、前言
Spring AOP在使用过程中需要注意一些问题,也就是平时我们说的陷阱,这些陷阱的出现是由于Spring AOP的实现方式造成的。对于这些缺陷本人坚持的观点是:一是每一样技术都或多或少有它的局限性,很难称得上完美,只要掌握其实现原理,在使用时不要掉进陷阱就行,也就是进行规避;二是更进一步讲,我们应该接受这就是技术本身的特点,也说不上什么缺陷,它本身就在“那里”,只是我们要的结果是“这样”,而它表现的是“那样”,恰好不是我们想要的而已。
对于Spring AOP的陷阱,我总结了以下两个方面,现在分别进行介绍。
2、嵌套方法拦截失效
2.1 问题场景
通过例子来讲解这样更好,首先加上注解配置:
<!-- 启用注解式AOP --> <aop:aspectj-autoproxy/>
然后定义一个切面,代码如下:
![](https://i-blog.csdnimg.cn/blog_migrate/961ddebeb323a10fe0623af514929fc1.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.................."); } }
测试代码:
![](https://i-blog.csdnimg.cn/blog_migrate/961ddebeb323a10fe0623af514929fc1.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."); } }
测试结果:
说明嵌套在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的代码逻辑相当清晰:
![](https://i-blog.csdnimg.cn/blog_migrate/961ddebeb323a10fe0623af514929fc1.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"/>
代码如下所示:
![](https://i-blog.csdnimg.cn/blog_migrate/8f900a89c6347c561fdf2122f13be562.gif)
结果:work方法中抛出异常,但是没有影响事务的回滚,说明事务在子线程中失效了。
3.2 解决方案
只需要将多线程中的方法提出来,或者作为另一个Service类中的方法即可。
![](https://i-blog.csdnimg.cn/blog_migrate/8f900a89c6347c561fdf2122f13be562.gif)
上面只是一个简单的例子,用于进行问题说明。
a、如果去掉多线程,将方法放在同一个类里,Spring则会根据事务的传播配置参数,是否重新启用新的事务。
b、如果将方法独立出来放在新的类里,并且该方法也配置了事务,则会重新启用新的事务。
3.3 原因分析
Spring的事务处理为了与数据访问解耦,它提供了一套处理数据资源的机制,而这个机制与上文中的原理相差无几,也是采用的ThreadLocal的方式。
在编程中,Service实例都是单例的无状态的,事务管理则需要加入事务控制的相关状态变量,使得Service实例不再是无状态线程安全的,解决这个问题的方式就是使用ThreadLocal。
通过使用ThreadLocal将数据源绑定在当前线程上,在当前线程的事务中,从设定的地方去取连接就会是同一个数据库连接,这样操作事务就会在同一个连接上进行。
如下图所示:
但是,ThreadLocal的特性是,绑定在当前线程中的变量不会自动传递到其它线程中(当然,InheritableThreadLocal可以在父子线程中间传递变量值,但是这需要特殊的使用场景),所以当开启子线程时,子线程并没有父线程的数据库连接资源。
对于上文提到的陷阱:如果另外开启线程,那么在新线程中将获取不到父线程的连接,事务要么失效,要么重新开启一个新的。
源代码如下:
![](https://i-blog.csdnimg.cn/blog_migrate/8f900a89c6347c561fdf2122f13be562.gif)
4、总结
本文总结了Spring AOP和事务的两个陷阱,在平时的实际开发中经常与遇到,只有深入了解了其中的原理,才会在工作中能够有效应对。