概要
过度
我们上文通过介绍AnnotationAwareAspectJAutoProxyCreator
后处理器的工作原理,撸通了在后处理中创建动态代理的思路。最后我们得到了一个动态代理,或者是JdkDynamicAopProxy
或者是ObjenesisCglibAopProxy
。
本文我们粗略介绍一下这两种动态代理的工作原理。【注意,非常粗略,只用于帮助理解,因为这块实在是有点复杂】
内容简介
本文通过结合很早之前对动态代理的基本使用的介绍,介绍了Spring AOP创建的动态代理的执行方法。
所属环节
代理工作原理
上下环节
上文:动态代理的创建
下文:AOP 基本功能介绍完成
源码解析
入口
我们上文根据情况new了JdkDynamicAopProxy
或者是ObjenesisCglibAopProxy
。接下来我们依次进行介绍。
JdkDynamicAopProxy
我们先回顾前面介绍的动态代理里面的思路:
- 先得到要代理的目标对象实例
- 构建一个代理类,实现
InvocationHandler
接口,在其中保存要增强的目标对象实例,并在其invoke()
方法中实现对目标对象调用的增强 - 利用
Proxy.newProxyInstance()
根据要代理的接口生成动态代理
因为我们这里不去探究jdk动态代理的实现细节,所以我们关注重点在于主干流程,根据经验,我们找到:
@Override
public Object getProxy() {
return getProxy(ClassUtils.getDefaultClassLoader());
}
@Override
public Object getProxy(@Nullable ClassLoader classLoader) {
if (logger.isDebugEnabled()) {
logger.debug("Creating JDK dynamic proxy: target source is " + this.advised.getTargetSource());
}
// 找出 JDK 动态代理要代理的接口
Class>[] proxiedInterfaces = AopProxyUtils.completeProxiedInterfaces(this.advised, true);
// 看我们找出的对应的接口的方法中有没有对 hashCode(),equals() 这种基本方法的覆盖
findDefinedEqualsAndHashCodeMethods(proxiedInterfaces);
return Proxy.newProxyInstance(classLoader, proxiedInterfaces, this);
}
和我们的思路基本一样,接下来看invoke()
方法:
// 根据JDK动态代理的依赖包,这里是调用被代理类的方法时实际调用的方法,Spring在这里进行了复杂的操作
// 包括对我们之前梳理出的 Advisor 的链式调用
public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {
MethodInvocation invocation;
Object oldProxy = null;
boolean setProxyContext = false;
TargetSource targetSource = this.advised.targetSource;
Object target = null;
try {
// 对一些Object默认方法的处理,如果目标对象没有特别实现,就在代理对象中自行调用默认逻辑
// 不要细究,关注主干逻辑
if (!this.equalsDefined && AopUtils.isEqualsMethod(method)) { //equals()
// The target does not implement the equals(Object) method itself.
return equals(args[0]);
} else if (!this.hashCodeDefined && AopUtils.isHashCodeMethod(method)) {//hashCode()
// The target does not implement the hashCode() method itself.
return hashCode();
} else if (method.getDeclaringClass() == DecoratingProxy.class) {
// There is only getDecoratedClass() declared -> dispatch to proxy config.
return AopProxyUtils.ultimateTargetClass(this.advised);
} else if (!this.advised.opaque && method.getDeclaringClass().isInterface() &&
method.getDeclaringClass().isAssignableFrom(Advised.class)) {
// Service invocations on ProxyConfig with the proxy config...
return AopUtils.invokeJoinpointUsingReflection(this.advised, method, args);
}
Object retVal;
if (this.advised.exposeProxy) { // 如果有配置,就把当前的代理对象暴露出去
// Make invocation available if necessary.
oldProxy = AopContext.setCurrentProxy(proxy);
setProxyContext = true;
}
// Get as late as possible to minimize the time we "own" the target,
// in case it comes from a pool.
target = targetSource.getTarget();
Class> targetClass = (target != null ? target.getClass() : null);
// Get the interception chain for this method.
List
如果重点关注主干逻辑的话,整体思路还是比较清晰的:
整体思路还是比较清晰的,这里只是根据前面筛选出的增强器进行一些安排,具体的实现,包括:
- 根据方法筛选需要的增强器,构建拦截器链
- 调用目标方法
- 调用构建的拦截器链
这三步和 AOP 具体实现密切相关的都委托给了外面的函数。如果有兴趣再深入吧。
CglibAopProxy
同样,我们先回顾前面介绍的动态代理里面的思路,这是CGLib最通用最基本的使用方法:
- 先得到要代理的目标对象实例
- 构建一个代理类,实现
MethodInterceptor
接口。 - 利用
Enhancer
根据要代理的对象实例生成动态代理
整体思路相近,只是:
- 在创建时JDK动态代理关注的是接口,所以创建时仅通过接口即可,需要在实现增强的逻辑中自行保存要代理的目标对象
- 在创建时CGLib动态代理关注的是目标对象,所以创建时需要目标对象,不需要在实现增强的逻辑中自行保存目标对象了,因为CGLib会给你传入
我们要关注的还是实现增强的主要逻辑,所以我们关注重点在于主干流程,根据经验,我们找到:
@Override
public Object getProxy() {
return getProxy(null);
}
@Override
public Object getProxy(@Nullable ClassLoader classLoader) {
if (logger.isDebugEnabled()) {
logger.debug("Creating CGLIB proxy: target source is " + this.advised.getTargetSource());
}
try {
Class> rootClass = this.advised.getTargetClass();
Assert.state(rootClass != null, "Target class must be available for creating a CGLIB proxy");
Class> proxySuperClass = rootClass;
if (ClassUtils.isCglibProxyClass(rootClass)) {
proxySuperClass = rootClass.getSuperclass();
Class>[] additionalInterfaces = rootClass.getInterfaces();
for (Class> additionalInterface : additionalInterfaces) {
this.advised.addInterface(additionalInterface);
}
}
// Validate the class, writing log messages as necessary.
validateClassIfNecessary(proxySuperClass, classLoader);
// Configure CGLIB Enhancer...
Enhancer enhancer = createEnhancer();
if (classLoader != null) {
enhancer.setClassLoader(classLoader);
if (classLoader instanceof SmartClassLoader &&
((SmartClassLoader) classLoader).isClassReloadable(proxySuperClass)) {
enhancer.setUseCache(false);
}
}
enhancer.setSuperclass(proxySuperClass);
enhancer.setInterfaces(AopProxyUtils.completeProxiedInterfaces(this.advised));
enhancer.setNamingPolicy(SpringNamingPolicy.INSTANCE);
enhancer.setStrategy(new ClassLoaderAwareUndeclaredThrowableStrategy(classLoader));
Callback[] callbacks = getCallbacks(rootClass);
Class>[] types = new Class>[callbacks.length];
for (int x = 0; x < types.length; x++) {
types[x] = callbacks[x].getClass();
}
// fixedInterceptorMap only populated at this point, after getCallbacks call above
enhancer.setCallbackFilter(new ProxyCallbackFilter(
this.advised.getConfigurationOnlyCopy(), this.fixedInterceptorMap, this.fixedInterceptorOffset));
enhancer.setCallbackTypes(types);
// Generate the proxy class and create a proxy instance.
return createProxyClassAndInstance(enhancer, callbacks);
} catch (CodeGenerationException | IllegalArgumentException ex) {
throw new AopConfigException("Could not generate CGLIB subclass of " + this.advised.getTargetClass() +
": Common causes of this problem include using a final class or a non-visible class",
ex);
} catch (Throwable ex) {
// TargetSource.getTarget() failed
throw new AopConfigException("Unexpected AOP exception", ex);
}
}
在CGLib中针对MethodInterceptor
实现了大量的内部类,例如EqualsInterceptor
,HashCodeInterceptor
,FixedChainStaticTargetInterceptor
之类的,入参是Advisor
。
这里感觉还是比较清爽的,因为借助了CGLib的调用链,没有像JDK动态代理那样出现了大量的if-else
,基本所有的功能,甚至暴露代理对象,都是用的XXXInterceptor
。每个XXXInterceptor
的思路也很清楚,判断增强器是否可用,可用就用,根据逻辑适当的往下一层调用即可。思路相当清晰。不再赘述了。