概要
过度
我们上文通过介绍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<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.
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);
// Proceed to the joinpoint through the interceptor chain.
retVal = invocation.proceed();
}
// Massage return value if necessary.
Class<?> returnType = method.getReturnType();
if (retVal != null && retVal == target &&
returnType != Object.class && returnType.isInstance(proxy) &&
!RawTargetAccess.class.isAssignableFrom(method.getDeclaringClass())) {
// Special case: it returned "this" and the return type of the method
// is type-compatible. Note that we can't help if the target sets
// a reference to itself in another returned object.
retVal = proxy;
} else if (retVal == null && returnType != Void.TYPE && returnType.isPrimitive()) {
throw new AopInvocationException(
"Null return value from advice does not match primitive return type for: " + method);
}
return retVal;
} finally {
if (target != null && !targetSource.isStatic()) {
// Must have come from TargetSource.
targetSource.releaseTarget(target);
}
if (setProxyContext) {
// Restore old proxy.
AopContext.setCurrentProxy(oldProxy);
}
}
}
如果重点关注主干逻辑的话，整体思路还是比较清晰的：
1.png
整体思路还是比较清晰的，这里只是根据前面筛选出的增强器进行一些安排，具体的实现，包括：
- 根据方法筛选需要的增强器，构建拦截器链
- 调用目标方法
- 调用构建的拦截器链
这三步和 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的思路也很清楚，判断增强器是否可用，可用就用，根据逻辑适当的往下一层调用即可。思路相当清晰。不再赘述了。
网友评论