解决Spring AOP 同类调用失效问题

扯一下沟通

本来这篇文章是想写关于职场上的沟通的,尽管我也是一个初入职场的小白。但是发现时间不太够,只好作罢,后面再补上吧。关于沟通,我总结起来就是"沟通渠道要畅通,沟通要主动,沟通要高效",关键就是理解对方的底层逻辑。当然,这些说辞一方面是跟我老大学的,一方面是看<<沟通的艺术>>得来的。嗯,我特指的是职场上的沟通,生活中,我是属于那种比较腼腆和内向的,说得难听一点就是怂。其实,估计很多人都不知道,周星驰星爷虽然在舞台上是收放自如,其实,据很多人反映,星爷其实在现实生活中,也是那种不太爱说话,腼腆的人的。以后再说吧。今天主要是想说一下关于"Spring AOP 同类调用失效问题"。

背景

当初刚到公司实习不久,就遇到一个问题:在同一个类中,调用有@redis,@Transactional的方法,发现注解失效了。因为这个问题,我当时纠结了很久。最后,还是老大一语惊醒梦中人,归根结底,还是Spring Aop原理没有理解彻底。今天就来聊一下关于"Spring AOP 同类调用失效问题"。

Spring AOP 同类调用失效问题
目录
  • 目标
  • 概述
  • 工作中遇到的实例
    • 源代码
    • 原因分析
  • 解决方法
    • 方法一
    • 方法二
    • 方法三
    • 总结
一 目标

深入探究"Spring AOP 同类调用失效问题",并且深刻理解Spring Aop的底层原理。

二 概述

在使用自定义注解形式的@redis做缓存时,@redis失效,分析原因。在此声明一下:@redis这个注解是的底层其实就是反射,这个以后我会分享一下自定义注解@redis的设计。如果你使用过SpringBoot的话,其实SpringBoot里面也是可以引入像@redis这样的注解的。这个注解的作用就是将方法的返回值缓存到redis中。

三 工作中遇到的实例

应用商店中根据imeiSnCode来查询安装列表,并且打算缓存到redis中。但是发现用以下的方法发现数据没有缓存到redis中。

1.源代码
@Service("installedRecordService")
public class InstalledRecordServiceImpl implements InstalledRecordService{

@Resource
private InstalledRecordMapper installedRecordMapper;

@Override
public void getInstalledApks() {
List<String> imeiSnCodes = installedRecordMapper.queryImeiCode();
if (imeiSnCodes != null && imeiSnCodes.size()> 0) {
for(int i=0;i<imeiSnCodes.size();i++){
getInstalledApk(imeiSnCodes.get(i));

}
}
}


@Redis(value=RedisKeys.INSTALLED_APK,keyArgs={0},sync=true,cacheNull=false,ttl=Constants.INSTALLED_APK_TIME,action=RedisAction.STAB_REDIS)
public List<InstalledRecord> getInstalledApk(final String code){
return installedRecordMapper.listByImeiSnCode(code);
}
}
2.原因分析

ED8213DD-F471-9EF0-05A0-3B28A2D01A4F.jpeg

首先我们看一下Spring Aop的原理图(此图摘抄于网络): 我长话短说,也就是说我们首先调用的是AOP代理对象而不是目标对象。但是我们使用this.getInstalledApk(imeiSnCodes.get(i))时,this表示的是当前的对象,而不是代理对象,因此注解失效。

三 解决方法

1.方法一

最简单的方法就是将getInstalledApks()方法放在另外的一个类中进行调用,就不会出现这种问题了。代码省略。

2.方法二

暴露AOP代理对象:

<aop:aspectj-autoproxy expose-proxy="true"/>

仍然在同一个类中调用代码,但是改为如下的形式:

@Service("installedRecordService")
public class InstalledRecordServiceImpl implements InstalledRecordService{

@Resource
private InstalledRecordMapper installedRecordMapper;

@Override
public void getInstalledApks() {
List<String> imeiSnCodes = installedRecordMapper.queryImeiCode();
if (imeiSnCodes != null && imeiSnCodes.size()> 0) {
for(int i=0;i<imeiSnCodes.size();i++){
//获取当前代理对象,进行调用
((InstalledRecordService) AopContext.currentProxy()).getInstalledApk(imeiSnCodes.get(i));
}
}
}
}

原理:AopContext的实现如下: (1).在进入代理对象之后通过AopContext.serCurrentProxy(proxy)暴露当前代理对象到ThreadLocal,并保存上次ThreadLocal绑定的代理对象为oldProxy。 (2).接下来我们可以通过 AopContext.currentProxy() 获取当前代理对象。 (3).在退出代理对象之前要重新将ThreadLocal绑定的代理对象设置为上一次的代理对象,即 AopContext.serCurrentProxy(oldProxy)。AopContext实现的源代码如下:

public abstract class AopContext {

private static final ThreadLocal<Object> currentProxy = new NamedThreadLocal<Object>("Current AOP proxy");

public static Object currentProxy() throws IllegalStateException {
Object proxy = currentProxy.get();
if (proxy == null) {
throw new IllegalStateException(
"Cannot find current proxy: Set 'exposeProxy' property on Advised to 'true' to make it available.");
}
return proxy;
}

static Object setCurrentProxy(Object proxy) {
Object old = currentProxy.get();
if (proxy != null) {
currentProxy.set(proxy);
}
else {
currentProxy.remove();
}
return old;
}
}

3.方法三

往实现类中注入自身。 仍然在同一个类中调用代码,但是改为如下的形式:

@Service("installedRecordService")
public class InstalledRecordServiceImpl implements InstalledRecordService{
//注入自身
@Resource
private InstalledRecordService installedRecordService;
@Resource
private InstalledRecordMapper installedRecordMapper;

@Override
public void getInstalledApks() {
List<String> imeiSnCodes = installedRecordMapper.queryImeiCode();
if (imeiSnCodes != null && imeiSnCodes.size()> 0) {
for(int i=0;i<imeiSnCodes.size();i++){
installedRecordService.getInstalledApk(imeiSnCodes.get(i));

}
}
}
4.总结

(1).在一个类内部调用时,被调用方法的 AOP 声明将不起作用。Spring 事务管理注解 @Transactional 也一样。

(2).对于基于接口动态代理的 AOP 事务增强来说,由于接口的方法都必然是 public 的,这就要求实现类的实现方法也必须是 public 的(不能是 protected、private 等),同时不能使用 static 的修饰符。所以,可以实施接口动态代理的方法只能是使用 public 或 public final 修饰符的方法,其他方法不可能被动态代理,相应的也就不能实施 AOP 增强,换句话说,即不能进行 Spring 事务增强了。

(3).基于 CGLib 字节码动态代理的方案是通过扩展被增强类,动态创建其子类的方式进行 AOP 增强植入的。由于使用 final、static、private 修饰符的方法都不能被子类覆盖,相应的,这些方法将无法实施 AOP 增强。所以方法签名必须特别注意这些修饰符的使用,以免使方法不小心成为事务管理的漏网之鱼。

(4).该例中的方法符合上述条件,但注解仍然失效,主要原因是在于同一类中的方法互相调用,调用者指向当前对象,所以无论是接口代理还是 cglib 代理都无法织入增强实现。

收藏 (0)
评论列表
正在载入评论列表...
我是有底线的
为您推荐
    暂时没有数据