Java JDK代理、CGLIB、AspectJ代理分析比较
前言
什么是代理,在Design patterns In java這個本書中是這樣描述的，簡單的說就是為某個對象提供一個代理，以控制對這個對象的訪問。在不修改源代碼的基礎(chǔ)上做方法增強(qiáng),代理是一種設(shè)計模式，又簡單的分為兩種。
- 靜態(tài)代理:代理類和委托類在代碼運行前關(guān)系就確定了,也就是說在代理類的代碼一開始就已經(jīng)存在了。
- 動態(tài)代理:動態(tài)代理類的字節(jié)碼在程序運行時的時候生成。
靜態(tài)代理
先來看一個靜態(tài)代理的例子，Calculator是一個計算器的接口類，定義了一個加法的接口方法，由CalculatorImpl類實現(xiàn)真正的加法操作.現(xiàn)在如果我們想對這個方法做一層靜態(tài)的代理，這兒實現(xiàn)了一個簡單的代理類實現(xiàn)了計算接口Calculator，構(gòu)造函數(shù)傳入的參數(shù)是真正的實現(xiàn)類，但是在調(diào)用這個代理類的add方法的時候我們在CalculatorImpl的實現(xiàn)方法執(zhí)行的前后分別做了一些操作。這樣的代理方式就叫做靜態(tài)代理(可以理解成一個簡單的裝飾模式)。
很明顯靜態(tài)代理的缺點,由于我們需要事先實現(xiàn)代理類,那么每個方法我都都需要去實現(xiàn)。如果我們要實現(xiàn)很多的代理類,那么工作量就太大了。動態(tài)代理的產(chǎn)生就是這樣而來的。
public interface Calculator {
//需要代理的接口
public int add(int a,int b);
//接口實現(xiàn)類,執(zhí)行真正的a+b操作
public static class CalculatorImpl implements Calculator{
@Override
public int add(int a, int b) {
System.out.println("doing ");
return a+b;
}
}
//靜態(tài)代理類的實現(xiàn).代碼已經(jīng)實現(xiàn)好了.
public static class CalculatorProxy implements Calculator{
private Calculator calculator;
public CalculatorProxy(Calculator calculator) {
this.calculator=calculator;
}
@Override
public int add(int a, int b) {
//執(zhí)行一些操作
System.out.println("begin ");
int result = calculator.add(a, b);
System.out.println("end ");
return result;
}
}
}
動態(tài)代理
使用動態(tài)代理可以讓代理類在程序運行的時候生成代理類，我們只需要為一類代理寫一個具體的實現(xiàn)類就行了，所以實現(xiàn)動態(tài)代理要比靜態(tài)代理簡單許多，省了不少重復(fù)的工作。在JDK的方案中我們只需要這樣做可以實現(xiàn)動態(tài)代理了。
public class ProxyFactory implements InvocationHandler {
private Class<?> target;
private Object real;
//委托類class
public ProxyFactory(Class<?> target){
this.target=target;
}
//實際執(zhí)行類bind
public Object bind(Object real){
this.real=real;
//利用JDK提供的Proxy實現(xiàn)動態(tài)代理
return Proxy.newProxyInstance(target.getClassLoader(),new Class[]{target},this);
}
@Override
public Object invoke(Object o, Method method, Object[] args) throws Throwable {
//代理環(huán)繞
System.out.println("begin");
//執(zhí)行實際的方法
Object invoke = method.invoke(real, args);
System.out.println("end");
return invoke;
}
public static void main(String[] args) {
Calculator proxy =(Calculator) new ProxyFactory(Calculator.class).bind(new Calculator.CalculatorImpl());
proxy.add(1,2);
}
}
利用JDK的proxy實現(xiàn)代理動態(tài)代理，有幾個關(guān)鍵點，一個就是InvocationHandler接口，這個方法中的invoke方法是執(zhí)行代理時會執(zhí)行的方法。所以我們所有代理需要執(zhí)行的邏輯都會寫在這里面,invo參數(shù)里面的method可以使用java 反射調(diào)用真實的實現(xiàn)類的方法，我們在這個方法周圍做一些代理邏輯工作就可以了。上面的代碼會把Calculator接口的所有方法全部在程序運行時代理。不用我們一個個的去寫靜態(tài)代理的方法。
JDK動態(tài)代理的原理
先看Proxy.newProxyInstance(...)方法中的具體實現(xiàn)(省略大部分方法)。在下面的代碼中會通過getProxyClass0(...)方法得到class對象，然后給把InvocationHandler已構(gòu)造參數(shù)實例化代理對象。思路還是挺清晰的,但是如果要一探究竟我們還是得知道代理對象到底是什么樣的，如何實現(xiàn)的代理呢？
public static Object newProxyInstance(ClassLoader loader,Class<?>[] interfaces,InvocationHandler h)throws IllegalArgumentException
{
//......
/*
*得到代理的對象的class對象。
*/
Class<?> cl = getProxyClass0(loader, intfs);
/*
* 給class 對象構(gòu)造函數(shù)傳入InvocationHandler 實例化對象
*/
//.....
return newInstance(cons, ih);
//....
}
在getProxyClass0（..）方法中有下面這段代碼.顧名思義這段代碼應(yīng)該是對代理的字節(jié)碼做了緩存.這是顯而易見的，我們不會每次調(diào)用都去生成代理對象。需要對代理對象緩存。我們發(fā)現(xiàn)緩存是用的一個叫WeakCache的類。我們不探究這個類具體的工作是怎樣的，我們只需要看我們的字節(jié)碼是如何生成的.注釋中ProxyClassFactory這個類應(yīng)該是我們需要尋找的類。
// If the proxy class defined by the given loader implementing
// the given interfaces exists, this will simply return the cached copy;
// otherwise, it will create the proxy class via the ProxyClassFactory
return proxyClassCache.get(loader, interfaces);
從ProxyClassFactory中下面的方法可以看到具體生成字節(jié)流的方法是ProxyGenerator.generateProxyClass(..).最后通過native方法生成Class對象。同時對class對象的包名稱有一些規(guī)定比如命名為com.meituan.Utils$proxy0。要想得到字節(jié)碼實例我們需要先下載這部分字節(jié)流,然后通過反編譯得到j(luò)ava代碼。
if (proxyPkg == null) {
//包名稱，如com.meituan.com.Utils 用。分割
// if no non-public proxy interfaces, use com.sun.proxy package
proxyPkg = ReflectUtil.PROXY_PACKAGE + ".";
}
/*
* Choose a name for the proxy class to generate. proxyClassNamePrefix=`$proxy` 前綴默認(rèn)是包名稱加$proxy +自增的號碼
*/
long num = nextUniqueNumber.getAndIncrement();
String proxyName = proxyPkg + proxyClassNamePrefix + num;
byte[] proxyClassFile = ProxyGenerator.generateProxyClass(proxyName, interfaces);
//native 方法
return defineClass0(loader, proxyName,proxyClassFile, 0, proxyClassFile.length);
用ProxyGenerator.generateProxyClass(..)方法生成字節(jié)流，然后寫進(jìn)硬盤.假設(shè)我把proxyName定義為Calcultor$ProxyCode.我們先在https://bitbucket.org/mstrobel/procyon/downloads?下載一個反編譯的jar包。然后運行下面的代碼，我們得到了一個Calcultor$ProxyCode.class的文件.然后在目錄下使用命令java -jar procyon-decompiler-0.5.29.jar Calcultor$ProxyCode.class?就能得到Calcultor$ProxyCode.java文件。 當(dāng)然也可以實現(xiàn)在線反編譯http://javare.cn/網(wǎng)站反編譯然后下載文件
public static void main(String[] args) {
//傳入Calculator接口
ProxyUtils.generateClassFile(Calculator.class,"Calcultor$ProxyCode");
}
public static void generateClassFile(Class clazz,String proxyName)
{
//根據(jù)類信息和提供的代理類名稱，生成字節(jié)碼
byte[] classFile = ProxyGenerator.generateProxyClass(proxyName,new Class[]{clazz});
String paths = clazz.getResource(".").getPath();
System.out.println(paths);
FileOutputStream out = null;
//保留到硬盤中
out = new FileOutputStream(paths+proxyName+".class");
out.write(classFile);
out.flush();
//...
下面的代碼是就是反編譯過來的Calcultor$ProxyCode類。可以發(fā)現(xiàn)這個類實現(xiàn)了我們需要代理的接口Calculator。且他的構(gòu)造函數(shù)確實是需要傳遞一個InvocationHandler對象,那么現(xiàn)在的情況就是我們的生成了一個代理類,這個代理類是我們需要代理的接口的實現(xiàn)類。我們的接口中定義了add和reduce方法,在這個代理類中幫我們實現(xiàn)了，并且全部變成了final的。同時覆蓋了一些Object類中的方法。那我們現(xiàn)在以reduce這個方法舉例,方法中會調(diào)用InvocationHandler類中的invoke方法(也就是我們實現(xiàn)的邏輯的地方)。同時把自己的Method對象，參數(shù)列表等傳入進(jìn)去。
public final class Calcultor$ProxyCode extends Proxy implements Calculator {
private static Method m1;
private static Method m4;
private static Method m0;
private static Method m3;
private static Method m2;
public Calcultor$ProxyCode(InvocationHandler var1) throws {
super(var1);
}
public final boolean equals(Object var1) throws {
try {
return ((Boolean)super.h.invoke(this, m1, new Object[]{var1})).booleanValue();
} catch (RuntimeException | Error var3) {
throw var3;
} catch (Throwable var4) {
throw new UndeclaredThrowableException(var4);
}
}
public final int reduce(int var1, int var2) throws {
try {
return ((Integer)super.h.invoke(this, m4, new Object[]{Integer.valueOf(var1), Integer.valueOf(var2)})).intValue();
} catch (RuntimeException | Error var4) {
throw var4;
} catch (Throwable var5) {
throw new UndeclaredThrowableException(var5);
}
}
public final int hashCode() throws {
try {
return ((Integer)super.h.invoke(this, m0, (Object[])null)).intValue();
} catch (RuntimeException | Error var2) {
throw var2;
} catch (Throwable var3) {
throw new UndeclaredThrowableException(var3);
}
}
public final int add(int var1, int var2) throws {
try {
return ((Integer)super.h.invoke(this, m3, new Object[]{Integer.valueOf(var1), Integer.valueOf(var2)})).intValue();
} catch (RuntimeException | Error var4) {
throw var4;
} catch (Throwable var5) {
throw new UndeclaredThrowableException(var5);
}
}
public final String toString() throws {
try {
return (String)super.h.invoke(this, m2, (Object[])null);
} catch (RuntimeException | Error var2) {
throw var2;
} catch (Throwable var3) {
throw new UndeclaredThrowableException(var3);
}
}
static {
try {
//static靜態(tài)塊加載每個方法的Method對象
m1 = Class.forName("java.lang.Object").getMethod("equals", new Class[]{Class.forName("java.lang.Object")});
m4 = Class.forName("jdkproxy.Calculator").getMethod("reduce", new Class[]{Integer.TYPE, Integer.TYPE});
m0 = Class.forName("java.lang.Object").getMethod("hashCode", new Class[0]);
m3 = Class.forName("jdkproxy.Calculator").getMethod("add", new Class[]{Integer.TYPE, Integer.TYPE});
m2 = Class.forName("java.lang.Object").getMethod("toString", new Class[0]);
} catch (NoSuchMethodException var2) {
throw new NoSuchMethodError(var2.getMessage());
} catch (ClassNotFoundException var3) {
throw new NoClassDefFoundError(var3.getMessage());
}
}
}
JDK動態(tài)代理小結(jié)
現(xiàn)在我們對JDK代理有個簡單的源碼級別的認(rèn)識,理清楚一下思路:JDK會幫我們在運行時生成一個代理類,這個代理類實際上就是我們需要代理的接口的實現(xiàn)類。實現(xiàn)的方法里面會調(diào)用InvocationHandler類中的invoke方法,并且同時傳入自身被調(diào)用的方法的的Method對象和參數(shù)列表方便我們編碼實現(xiàn)方法的調(diào)用。比如我們調(diào)用reduce方法，那么我們就可以通過Method.Invoke(Object obj, Object... args)調(diào)用我們具體的實現(xiàn)類,再在周圍做一些代理做的事兒。就實現(xiàn)了動態(tài)代理。我們對JDK的特性做一些簡單的認(rèn)識：
- JDK動態(tài)代理只能代理有接口的類,并且是能代理接口方法,不能代理一般的類中的方法
- 提供了一個使用InvocationHandler作為參數(shù)的構(gòu)造方法。在代理類中做一層包裝,業(yè)務(wù)邏輯在invoke方法中實現(xiàn)
- 重寫了Object類的equals、hashCode、toString，它們都只是簡單的調(diào)用了InvocationHandler的invoke方法，即可以對其進(jìn)行特殊的操作，也就是說JDK的動態(tài)代理還可以代理上述三個方法
- 在invoke方法中我們甚至可以不用Method.invoke方法調(diào)用實現(xiàn)類就返回。這種方式常常用在RPC框架中,在invoke方法中發(fā)起通信調(diào)用遠(yuǎn)端的接口等
CGLIB代理
JDK中提供的生成動態(tài)代理類的機(jī)制有個鮮明的特點是：某個類必須有實現(xiàn)的接口，而生成的代理類也只能代理某個類接口定義的方法。那么如果一個類沒有實現(xiàn)接口怎么辦呢？這就有CGLIB的誕生了,前面說的JDK的代理類的實現(xiàn)方式是實現(xiàn)相關(guān)的接口成為接口的實現(xiàn)類,那么我們自然而然的可以想到用繼承的方式實現(xiàn)相關(guān)的代理類。CGLIB就是這樣做的。一個簡單的CGLIB代理是這樣實現(xiàn)的:
Enhancer enhancer=new Enhancer();
enhancer.setSuperclass(Calculator.class);
enhancer.setCallback(new MethodInterceptor() {
//類似invokerhanddler的invoke方法
@Override
public Object intercept(Object o, Method method, Object[] objects, MethodProxy methodProxy) throws Throwable {
System.out.println("begin");
Object invoke = methodProxy.invoke(new Calculator.CalculatorImpl(), objects);
System.out.println("end");
return invoke;
}
});
Calculator proxy =(Calculator) enhancer.create();
proxy.add(1,2);
CGLIB代理原理分析
通過在執(zhí)行動態(tài)代理的代碼前面加上一行代碼就可以得到生成的代理對象.代理對象的class文件會生成在你定義的路徑下。類似Calculator$CalculatorImpl$$EnhancerByCGLIB$$58419779.class這樣結(jié)構(gòu)。
System.setProperty(DebuggingClassWriter.DEBUG_LOCATION_PROPERTY, "${your path}");之后我們通過反編譯得到反編譯后的java文件。就上面的例子而言我們傳入的superclass是一個接口，并不是實現(xiàn)類。那我們得到的代理類會長成這樣:
//如果是接口代理類還是通過實現(xiàn)接口的方式
public class Calculator$$EnhancerByCGLIB$$40fd3cad implements Calculator, Factory{
//...
}
如果傳入的并不是接口，而是實現(xiàn)類的話，就會得到下面的代理類:
//如果是普通的類，會采用繼承的方式實現(xiàn)
public class Calculator$CalculatorImpl$$EnhancerByCGLIB$$58419779 extends CalculatorImpl implements Factory {
//...
}
但是不管是傳入的接口還是傳入的代理類，代碼的實體都是長得差不多的:
ublic class Calculator$CalculatorImpl$$EnhancerByCGLIB$$2849428a extends CalculatorImpl implements Factory {
private boolean CGLIB$BOUND;
private static final ThreadLocal CGLIB$THREAD_CALLBACKS;
private static final Callback[] CGLIB$STATIC_CALLBACKS;
private MethodInterceptor CGLIB$CALLBACK_0;
private InvocationHandler CGLIB$CALLBACK_1;
private static final Method CGLIB$say4$1$Method;
private static final MethodProxy CGLIB$say4$1$Proxy;
private static final Object[] CGLIB$emptyArgs;
private static final Method CGLIB$reduce$2$Method;
private static final MethodProxy CGLIB$reduce$2$Proxy;
private static final Method CGLIB$finalize$3$Method;
private static final MethodProxy CGLIB$finalize$3$Proxy;
//省略 clone等 定義
//初始化
static void CGLIB$STATICHOOK1() {
CGLIB$THREAD_CALLBACKS = new ThreadLocal();
CGLIB$emptyArgs = new Object[0];
Class var0 = Class.forName("jdkproxy.Calculator$CalculatorImpl$$EnhancerByCGLIB$$2849428a");
Class var1;
Method[] var10000 = ReflectUtils.findMethods(new String[]{"say4", "()V", "reduce", "(II)I"}, (var1 = Class.forName("jdkproxy.Calculator$CalculatorImpl")).getDeclaredMethods());
CGLIB$say4$1$Method = var10000[0];
CGLIB$say4$1$Proxy = MethodProxy.create(var1, var0, "()V", "say4", "CGLIB$say4$1");
CGLIB$reduce$2$Method = var10000[1];
CGLIB$reduce$2$Proxy = MethodProxy.create(var1, var0, "(II)I", "reduce", "CGLIB$reduce$2");
var10000 = ReflectUtils.findMethods(new String[]{"finalize", "()V", "equals", "(Ljava/lang/Object;)Z", "toString", "()Ljava/lang/String;", "hashCode", "()I", "clone", "()Ljava/lang/Object;"}, (var1 = Class.forName("java.lang.Object")).getDeclaredMethods());
CGLIB$finalize$3$Method = var10000[0];
CGLIB$finalize$3$Proxy = MethodProxy.create(var1, var0, "()V", "finalize", "CGLIB$finalize$3");
CGLIB$equals$4$Method = var10000[1];
CGLIB$equals$4$Proxy = MethodProxy.create(var1, var0, "(Ljava/lang/Object;)Z", "equals", "CGLIB$equals$4");
CGLIB$toString$5$Method = var10000[2];
CGLIB$toString$5$Proxy = MethodProxy.create(var1, var0, "()Ljava/lang/String;", "toString", "CGLIB$toString$5");
CGLIB$hashCode$6$Method = var10000[3];
CGLIB$hashCode$6$Proxy = MethodProxy.create(var1, var0, "()I", "hashCode", "CGLIB$hashCode$6");
CGLIB$clone$7$Method = var10000[4];
CGLIB$clone$7$Proxy = MethodProxy.create(var1, var0, "()Ljava/lang/Object;", "clone", "CGLIB$clone$7");
CGLIB$add$0 = Class.forName("jdkproxy.Calculator$CalculatorImpl").getDeclaredMethod("add", new Class[]{Integer.TYPE, Integer.TYPE});
}
//非接口中的方法，在實現(xiàn)類中定義的
final void CGLIB$say4$1() {
super.say4();
}
public final void say4() {
MethodInterceptor var10000 = this.CGLIB$CALLBACK_0;
if(this.CGLIB$CALLBACK_0 == null) {
CGLIB$BIND_CALLBACKS(this);
var10000 = this.CGLIB$CALLBACK_0;
}
if(var10000 != null) {
var10000.intercept(this, CGLIB$say4$1$Method, CGLIB$emptyArgs, CGLIB$say4$1$Proxy);
} else {
super.say4();
}
}
//綁定MethodInterceptor callback的方法會額外實現(xiàn)一個和原方法一模一樣的方法
final int CGLIB$reduce$2(int var1, int var2) {
return super.reduce(var1, var2);
}
public final int reduce(int var1, int var2) {
MethodInterceptor var10000 = this.CGLIB$CALLBACK_0;
if(this.CGLIB$CALLBACK_0 == null) {
CGLIB$BIND_CALLBACKS(this);
var10000 = this.CGLIB$CALLBACK_0;
}
if(var10000 != null) {
//調(diào)用MethodInterceptor中的intercept方法
Object var3 = var10000.intercept(this, CGLIB$reduce$2$Method, new Object[]{new Integer(var1), new Integer(var2)}, CGLIB$reduce$2$Proxy);
return var3 == null?0:((Number)var3).intValue();
} else {
return super.reduce(var1, var2);
}
}
final void CGLIB$finalize$3() throws Throwable {
super.finalize();
}
protected final void finalize() throws Throwable {
MethodInterceptor var10000 = this.CGLIB$CALLBACK_0;
if(this.CGLIB$CALLBACK_0 == null) {
CGLIB$BIND_CALLBACKS(this);
var10000 = this.CGLIB$CALLBACK_0;
}
if(var10000 != null) {
var10000.intercept(this, CGLIB$finalize$3$Method, CGLIB$emptyArgs, CGLIB$finalize$3$Proxy);
} else {
super.finalize();
}
}
//省略 clone等
//得到MethodProxy對象
public static MethodProxy CGLIB$findMethodProxy(Signature var0) {
String var10000 = var0.toString();
switch(var10000.hashCode()) {
case -1574182249:
if(var10000.equals("finalize()V")) {
return CGLIB$finalize$3$Proxy;
}
break;
//省略
}
return null;
}
public final int add(int var1, int var2) {
try {
InvocationHandler var10000 = this.CGLIB$CALLBACK_1;
if(this.CGLIB$CALLBACK_1 == null) {
CGLIB$BIND_CALLBACKS(this);
var10000 = this.CGLIB$CALLBACK_1;
}
//調(diào)用invokeHandler中的invoke方法
return ((Number)var10000.invoke(this, CGLIB$add$0, new Object[]{new Integer(var1), new Integer(var2)})).intValue();
} catch (Error | RuntimeException var3) {
throw var3;
} catch (Throwable var4) {
throw new UndeclaredThrowableException(var4);
}
}
//...
//為每個方法綁定callback 根據(jù)實現(xiàn)fitler的不同會加載不同的callback
private static final void CGLIB$BIND_CALLBACKS(Object var0) {
Calculator$CalculatorImpl$$EnhancerByCGLIB$$2849428a var1 = (Calculator$CalculatorImpl$$EnhancerByCGLIB$$2849428a)var0;
if(!var1.CGLIB$BOUND) {
var1.CGLIB$BOUND = true;
Object var10000 = CGLIB$THREAD_CALLBACKS.get();
if(var10000 == null) {
var10000 = CGLIB$STATIC_CALLBACKS;
if(CGLIB$STATIC_CALLBACKS == null) {
return;
}
}
Callback[] var10001 = (Callback[])var10000;
var1.CGLIB$CALLBACK_1 = (InvocationHandler)((Callback[])var10000)[1];
var1.CGLIB$CALLBACK_0 = (MethodInterceptor)var10001[0];
}
}
public void setCallback(int var1, Callback var2) {
switch(var1) {
case 0:
this.CGLIB$CALLBACK_0 = (MethodInterceptor)var2;
break;
case 1:
this.CGLIB$CALLBACK_1 = (InvocationHandler)var2;
}
}
public Callback[] getCallbacks() {
CGLIB$BIND_CALLBACKS(this);
return new Callback[]{this.CGLIB$CALLBACK_0, this.CGLIB$CALLBACK_1};
}
//初始化我們定義的 callback
public void setCallbacks(Callback[] var1) {
this.CGLIB$CALLBACK_0 = (MethodInterceptor)var1[0];
this.CGLIB$CALLBACK_1 = (InvocationHandler)var1[1];
}
static {
CGLIB$STATICHOOK1();
}
}
上面這一份代碼整個代理的流程仿佛是差不多的，都是在調(diào)用方法的時候router到InvokeHandler或者M(jìn)ethodInterceptor。為什么會有兩種呢，因為CGLIB提供了filter的機(jī)制，可以讓不同的方法代理到不同的callback中,如下面這樣:
enhancer.setCallbacks(new Callback[]{new MethodInterceptor() {
//...
},new InvocationHandler() {
//...
}});
enhancer.setCallbackFilter(new CallbackFilter() {
@Override
public int accept(Method method) {
//返回的下標(biāo)和在Callback數(shù)組中的下標(biāo)對應(yīng),下面表達(dá)的是reduce方法綁定MethodInterceptor
if(method.getName().equals("reduce")) return 1;
return 0;
}
});
這兩種callback不一樣的地方很顯而易見, MethodInterceptor的方法參數(shù)多了一個MethodProxy對象，在使用這個對象的時候的時候有兩個方法可以讓我們調(diào)用:
public Object invoke(Object obj, Object[] args) throws Throwable {
//...
this.init();
MethodProxy.FastClassInfo e = this.fastClassInfo;
return e.f1.invoke(e.i1, obj, args);//f1 i1
//...
}
public Object invokeSuper(Object obj, Object[] args) throws Throwable {
//...
this.init();
MethodProxy.FastClassInfo e = this.fastClassInfo;
return e.f2.invoke(e.i2, obj, args);//f2 i2
//...
}
private static class FastClassInfo {
FastClass f1;//委托類
FastClass f2;//代理類
int i1;//委托類方法索引
int i2;//代理類方法索引
private FastClassInfo() {
}
}
FastClass是Cglib實現(xiàn)的一種通過給方法建立下標(biāo)索引來訪問方法的策略，為了繞開反射。 上面的描述代表MethodPeoxy可以根據(jù)對方法建立索引調(diào)用方法，而不需要使用傳統(tǒng)Method的invoke反射調(diào)用，提高了性能，當(dāng)然額外的得多生成一些類信息,比如在最開始的代理類中我們也可以看到MethodProxy也是有通過索引來做的，這樣的話做到了FastClass,FastClass大致是這樣實現(xiàn)的:
class FastTest {
public int getIndex(String signature){
//方法簽名做hash
switch(signature.hashCode()){
case 3078479:
return 1;
case 3108270:
return 2;
}
return -1;
}
public Object invoke(int index, Object o, Object[] ol){
//根據(jù)index調(diào)用方法，
Test t = (Test) o;
switch(index){
case 1:
t.f();
case 2:
t.g();
}
}
}
所以在使用MethodInterceptor的時候可以這樣使用:
public Object intercept(Object o, Method method, Object[] objects, MethodProxy methodProxy) throws Throwable {
//傳入o 也就是代理對象本身,如果不傳入o會拋出類似
//java.lang.ClassCastException: jdkproxy.Calculator$CalculatorImpl cannot be cast to jdkproxy.Calculator$CalculatorImpl$$EnhancerByCGLIB$$8e994f7f
//這樣的異常
//
Object o1 = methodProxy.invokeSuper(o, objects);
return o1;
}
實際上調(diào)用的就是綁定了MethodInterceptor callback接口然后在代理類中額外生成的類如上面所標(biāo)注的final int CGLIB$reduce$2(int var1, int var2)?方便MethodProxy調(diào)用，但有個前提是你傳入的superclass不能是接口,super.xxx(*)會調(diào)用失敗，會拋出NoSuchMethodError錯誤。
小結(jié)
- CGlib可以傳入接口也可以傳入普通的類，接口使用實現(xiàn)的方式,普通類使用會使用繼承的方式生成代理類.
- 由于是繼承方式,如果是 static方法,private方法,final方法等描述的方法是不能被代理的
- 做了方法訪問優(yōu)化，使用建立方法索引的方式避免了傳統(tǒng)Method的方法反射調(diào)用.
- 提供callback 和filter設(shè)計，可以靈活地給不同的方法綁定不同的callback。編碼更方便靈活。
- CGLIB會默認(rèn)代理Object中finalize,equals,toString,hashCode,clone等方法。比JDK代理多了finalize和clone。
AspectJ靜態(tài)編譯織入
前面兩種都是說的在代碼運行時動態(tài)的生成class文件達(dá)到動態(tài)代理的目的，那我們現(xiàn)在回到靜態(tài)代理，靜態(tài)代理唯一的缺點就是我們需要對每一個方法編寫我們的代理邏輯，造成了工作的繁瑣和復(fù)雜。AspectJ就是為了解決這個問題，在編譯成class字節(jié)碼的時候在方法周圍加上業(yè)務(wù)邏輯。復(fù)雜的工作由特定的編譯器幫我們做。
AOP有切面(Aspect)、連接點(joinpoint)、通知(advice)、切入點(Pointcut)、目標(biāo)對象(target)等概念,這里不詳細(xì)介紹這些概念.
如何做ASpectj開發(fā),這里使用的是maven插件,詳細(xì)使用文檔http://www.mojohaus.org/aspectj-maven-plugin/examples/differentTestAndCompile.html:
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>aspectj-maven-plugin</artifactId>
<version>1.5</version>
<executions>
<execution>
<goals>
<goal>compile</goal>
<goal>test-compile</goal>
</goals>
</execution>
</executions>
<configuration>
<weaveDependencies>
<!--是否要植入jar-->
<!--<weaveDependency>-->
<!--<groupId>com.meituan.inf</groupId>-->
<!--<artifactId>xmd-common-log4j2</artifactId>-->
<!--</weaveDependency>-->
</weaveDependencies>
<source>1.6</source>
<target>1.6</target>
<encoding>UTF-8</encoding>
<complianceLevel>1.6</complianceLevel>
<verbose>true</verbose>
<showWeaveInfo>true</showWeaveInfo>
</configuration>
</plugin>
然后編寫Aspectj的文件.可以編寫.ajc文件,或者使用java文件也可以,Aspectj語法可以參考http://sishuok.com/forum/posts/list/281.html?此文章：
//表示對實現(xiàn)了Mtrace接口的類，并且參數(shù)數(shù)Integer 同時方法中有@RequestMapping 注解的方法插入代理
@Pointcut("execution(* com.meituan.deploy.Mtrace+.*(java.lang.Integer)) && @annotation(org.springframework.web.bind.annotation.RequestMapping)")
public void zhiru2() {
}
@Before(value = "zhiru2()")//前面植入
public void doBeforeTask2(JoinPoint point) {
//方法調(diào)用前植入
System.out.println("=========BEFORE=========");
}
@After("zhiru2()")//后面植入
public void after(JoinPoint point) {
//方法調(diào)用后植入
System.out.println("===========AFTER=======");
}
@AfterThrowing("zhiru2()")
public void afterthrowing(JoinPoint point) {
System.out.println("===========throwing=======");
}
@AfterReturning("zhiru2()")
public void afterRutuen(JoinPoint point) {
System.out.println("===========return=======");
}
編寫好ASpectj文件之后，編譯代碼就能夠得到靜態(tài)織入的class文件了,接下來簡單的介紹一下AspectJ是在哪個地方植入代碼到class文件的.
AspectJ原理分析
反編譯過后得到的java代碼如下:
@RequestMapping({"/hello"})
public ModelAndView helloMyMethodName(Integer name) throws SQLException {
JoinPoint var2 = Factory.makeJP(ajc$tjp_0, this, this, name);
Object var7;
try {
Object var5;
try {
//調(diào)用before
Aspectj.aspectOf().doBeforeTask2(var2);
System.out.println(name);
Util.report("xiezhaodong");
var5 = null;
} catch (Throwable var8) {
Aspectj.aspectOf().after(var2);
throw var8;
}
//調(diào)用after
Aspectj.aspectOf().after(var2);
var7 = var5;
} catch (Throwable var9) {
//調(diào)用拋出異常
Aspectj.aspectOf().afterthrowing(var2);
throw var9;
}
//調(diào)用return
Aspectj.aspectOf().afterRutuen(var2);
return (ModelAndView)var7;
}
@RequestMapping({"/hello2"})
public ModelAndView helloMyMethodName222(String name) throws SQLException {
return new ModelAndView("hello", "name", name);
}
上面兩個方法都實現(xiàn)了@ RequestMapping注解,類也實現(xiàn)類Mtrace接口。但是因為傳入?yún)?shù)的類型不同，所以只有第一個方法被織入了代理的方法,在真正的方法快周圍分表調(diào)用了before、after、afterThrowing、afterRutnrn等方法。Aspectj簡單的原理就是這樣.更加深入的原理解析暫時就不做了。
小結(jié)
- Aspectj并不是動態(tài)的在運行時生成代理類，而是在編譯的時候就植入代碼到class文件
- 由于是靜態(tài)織入的，所以性能相對來說比較好
- Aspectj不受類的特殊限制,不管方法是private、或者static、或者final的,都可以代理
- Aspectj不會代理除了限定方法之外任何其他諸如toString(),clone()等方法
Spring Aop中的代理
Spring代理實際上是對JDK代理和CGLIB代理做了一層封裝，并且引入了AOP概念:Aspect、advice、joinpoint等等，同時引入了AspectJ中的一些注解@pointCut,@after,@before等等.Spring Aop嚴(yán)格的來說都是動態(tài)代理，所以實際上Spring代理和Aspectj的關(guān)系并不大.
Spring代理中org.springframework.aop.framework.ProxyFactory是關(guān)鍵,一個簡單的使用API編程的Spring AOP代理如下:
ProxyFactory proxyFactory =new ProxyFactory(Calculator.class, new MethodInterceptor() {
@Override
public Object invoke(MethodInvocation invocation) throws Throwable {
return null;
}
});
proxyFactory.setOptimize(false);
//得到代理對象
proxyFactory.getProxy();
在調(diào)用getProxy()時，會優(yōu)先得到一個默認(rèn)的DefaultAopProxyFactory.這個類主要是決定到底是使用JDK代理還是CGLIB代理:
public AopProxy createAopProxy(AdvisedSupport config) throws AopConfigException {
//optimize 優(yōu)化，如上列代碼編程true會默認(rèn)進(jìn)入if
//ProxyTargetClass 是否對具體類進(jìn)行代理
//判斷傳入的class 是否有接口。如果沒有也會進(jìn)入選擇
if (config.isOptimize() || config.isProxyTargetClass() || hasNoUserSuppliedProxyInterfaces(config)) {
Class targetClass = config.getTargetClass();
if (targetClass == null) {
throw new AopConfigException("TargetSource cannot determine target class: " +
"Either an interface or a target is required for proxy creation.");
}
//如果目標(biāo)是接口的話還是默認(rèn)使用JDK
if (targetClass.isInterface()) {
return new JdkDynamicAopProxy(config);
}
return CglibProxyFactory.createCglibProxy(config);
}
else {
return new JdkDynamicAopProxy(config);
}
}
可以看見一些必要的信息，我們在使用Spring AOP的時候通常會在XML配置文件中設(shè)置<aop:aspectj-autoproxy proxy-target-class="true">?來使用CGlib代理。現(xiàn)在我們可以發(fā)現(xiàn)只要三個參數(shù)其中一個為true，便可以有機(jī)會選擇使用CGLIB代理。但是是否一定會使用還是得看傳入的class到底是個怎樣的類。如果是接口，就算開啟了這幾個開關(guān)，最后還是會自動選擇JDK代理。
JdkDynamicAopProxy這個類實現(xiàn)了InvokeHandler接口，最后調(diào)用getProxy():
public Object getProxy(ClassLoader classLoader) {
//...
//返回代理對象
return Proxy.newProxyInstance(classLoader, proxiedInterfaces, this);
}
那么JdkDynamicAopProxy中的invoke方法就是最核心的方法了(實現(xiàn)了InvokeHandler接口):
/**
* 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 {
MethodInvocation invocation;
Object oldProxy = null;
boolean setProxyContext = false;
TargetSource targetSource = this.advised.targetSource;
Class targetClass = null;
Object target = null;
try {
//是否實現(xiàn)equals和hashCode，否則不代理。因為JDK代理會默認(rèn)代理這兩個方法
if (!this.equalsDefined && AopUtils.isEqualsMethod(method)) {
// The target does not implement the equals(Object) method itself.
return equals(args[0]);
}
if (!this.hashCodeDefined && AopUtils.isHashCodeMethod(method)) {
// The target does not implement the hashCode() method itself.
return hashCode();
}
//不能代理adviser接口和子接口自身
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;
//代理類和ThreadLocal綁定
if (this.advised.exposeProxy) {
// Make invocation available if necessary.
oldProxy = AopContext.setCurrentProxy(proxy);
setProxyContext = true;
}
//合一從TargetSource得到一個實例對象，可實現(xiàn)接口獲得
target = targetSource.getTarget();
if (target != null) {
targetClass = target.getClass();
}
// 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.
//如果沒有定義攔截器鏈。直接調(diào)用方法不進(jìn)行代理
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);
//執(zhí)行攔截器鏈。通過proceed遞歸調(diào)用
// 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.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.
//如果返回值是this 直接返回代理對象本身
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);
}
}
}
下面來分析整個代理的攔截器是怎么運行的,ReflectiveMethodInvocation這個類的proceed()方法負(fù)責(zé)遞歸調(diào)用所有的攔截的織入。
public Object proceed() throws Throwable {
//list的索引從-1開始。
if (this.currentInterceptorIndex == this.interceptorsAndDynamicMethodMatchers.size() - 1) {
//所有interceptor都被執(zhí)行完了，直接執(zhí)行原方法
return invokeJoinpoint();
}
//得到一個interceptor。不管是before還是after等織入，都不受在list中的位置影響。
Object interceptorOrInterceptionAdvice =
this.interceptorsAndDynamicMethodMatchers.get(++this.currentInterceptorIndex);
//....
//調(diào)用invoke方法
return ((MethodInterceptor) interceptorOrInterceptionAdvice).invoke(this);
}
}
需要注意的是invoke方法中傳入的是this。在MethodInvocation中又可以調(diào)用procced來實現(xiàn)遞歸調(diào)用。比如像下面這樣:
new MethodInterceptor() {
@Override
public Object invoke(MethodInvocation invocation) throws Throwable {
Object re= invocation.proceed();
return re;
}
}
那么要實現(xiàn)織入，只需要控制織入的代碼和調(diào)用proceed方法的位置，在Spring中的before織入是這樣實現(xiàn)的:
public class MethodBeforeAdviceInterceptor implements MethodInterceptor, Serializable {
private MethodBeforeAdvice advice;
public Object invoke(MethodInvocation mi) throws Throwable {
//調(diào)用before實際代碼
this.advice.before(mi.getMethod(), mi.getArguments(), mi.getThis() );
//繼續(xù)迭代
return mi.proceed();
}
afterRuturning是這樣實現(xiàn)的:
public class AfterReturningAdviceInterceptor implements MethodInterceptor, AfterAdvice, Serializable {
private final AfterReturningAdvice advice;
public Object invoke(MethodInvocation mi) throws Throwable {
Object retVal = mi.proceed();
//只要控制和mi.proceed()調(diào)用的位置關(guān)系就可以實現(xiàn)任何狀態(tài)的織入效果
this.advice.afterReturning(retVal, mi.getMethod(), mi.getArguments(), mi.getThis());
return retVal;
}
下面這幅流程圖是一個一個包含上述一個before織入和一個afterReturning織入的流程圖:
?
要實現(xiàn)這種環(huán)繞的模式其實很簡單，下面提供一個最簡單的實現(xiàn)，利用迭代的思想很簡單的實現(xiàn)了鏈?zhǔn)秸{(diào)用。并且可擴(kuò)展性非常高。和AspectJ的直接靜態(tài)織入改變代碼結(jié)構(gòu)的方式來分別織入before、after等來說。這種方式設(shè)計更優(yōu)雅。但是在SpringMVC中攔截器卻并不是這種方式實現(xiàn)的，哈哈。
public interface MethodInterceptor {
Object invoke(Invocation invocation);
public static class beforeMethodInterceptor implements MethodInterceptor{
private String name;
public beforeMethodInterceptor(String name) {
this.name=name;
}
@Override
public Object invoke(Invocation invocation) {
System.out.println("before method "+name);
return invocation.proceed();
}
}
public static class AfterRuturningMethodInterceptor implements MethodInterceptor{
@Override
public Object invoke(Invocation invocation) {
Object proceed = invocation.proceed();
System.out.println("afterRuturning method 1");
return proceed;
}
}
public static class AfterMethodInterceptor implements MethodInterceptor{
@Override
public Object invoke(Invocation invocation) {
try {
return invocation.proceed();
}finally {
System.out.println("after");
}
}
}
}
public interface Invocation {
Object proceed();
public static class MethodInvocation implements Invocation{
private List<MethodInterceptor> list;
private int index=-1;
private int ListSize=0;
public MethodInvocation(List<MethodInterceptor> list) {
this.list=list;
ListSize=list.size();
}
@Override
public Object proceed() {
if(index==ListSize-1){
System.out.println("執(zhí)行方法實體");
return "返回值";
}
MethodInterceptor methodInterceptor = list.get(++index);
return methodInterceptor.invoke(this);
}
}
}
小結(jié)
Spring AOP封裝了JDK和CGLIB的動態(tài)代理實現(xiàn)，同時引入了AspectJ的編程方式和注解。使得可以使用標(biāo)準(zhǔn)的AOP編程規(guī)范來編寫代碼外，還提供了多種代理方式選擇。可以根據(jù)需求來選擇最合適的代理模式。同時Spring也提供了XML配置的方式實現(xiàn)AOP配置。可以說是把所有想要的都做出來了，Spring是在平時編程中使用動態(tài)代理的不二選擇.
總結(jié)
以上是生活随笔為你收集整理的Java JDK代理、CGLIB、AspectJ代理分析比较的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 浅谈推荐系统基础
- 下一篇： MySQL事务隔离级别和Spring事务