Java JDK代理、CGLIB、AspectJ代理分析比较
前言
什么是代理,在Design patterns In java這個本書中是這樣描述的，簡單的說就是為某個對象提供一個代理，以控制對這個對象的訪問。在不修改源代碼的基礎上做方法增強,代理是一種設計模式，又簡單的分為兩種。
- 靜態代理:代理類和委托類在代碼運行前關系就確定了,也就是說在代理類的代碼一開始就已經存在了。
- 動態代理:動態代理類的字節碼在程序運行時的時候生成。
靜態代理
先來看一個靜態代理的例子，Calculator是一個計算器的接口類，定義了一個加法的接口方法，由CalculatorImpl類實現真正的加法操作.現在如果我們想對這個方法做一層靜態的代理，這兒實現了一個簡單的代理類實現了計算接口Calculator，構造函數傳入的參數是真正的實現類，但是在調用這個代理類的add方法的時候我們在CalculatorImpl的實現方法執行的前后分別做了一些操作。這樣的代理方式就叫做靜態代理(可以理解成一個簡單的裝飾模式)。
很明顯靜態代理的缺點,由于我們需要事先實現代理類,那么每個方法我都都需要去實現。如果我們要實現很多的代理類,那么工作量就太大了。動態代理的產生就是這樣而來的。
public interface Calculator {
//需要代理的接口
public int add(int a,int b);
//接口實現類,執行真正的a+b操作
public static class CalculatorImpl implements Calculator{
@Override
public int add(int a, int b) {
System.out.println("doing ");
return a+b;
}
}
//靜態代理類的實現.代碼已經實現好了.
public static class CalculatorProxy implements Calculator{
private Calculator calculator;
public CalculatorProxy(Calculator calculator) {
this.calculator=calculator;
}
@Override
public int add(int a, int b) {
//執行一些操作
System.out.println("begin ");
int result = calculator.add(a, b);
System.out.println("end ");
return result;
}
}
}
動態代理
使用動態代理可以讓代理類在程序運行的時候生成代理類，我們只需要為一類代理寫一個具體的實現類就行了，所以實現動態代理要比靜態代理簡單許多，省了不少重復的工作。在JDK的方案中我們只需要這樣做可以實現動態代理了。
public class ProxyFactory implements InvocationHandler {
private Class<?> target;
private Object real;
//委托類class
public ProxyFactory(Class<?> target){
this.target=target;
}
//實際執行類bind
public Object bind(Object real){
this.real=real;
//利用JDK提供的Proxy實現動態代理
return Proxy.newProxyInstance(target.getClassLoader(),new Class[]{target},this);
}
@Override
public Object invoke(Object o, Method method, Object[] args) throws Throwable {
//代理環繞
System.out.println("begin");
//執行實際的方法
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實現代理動態代理，有幾個關鍵點，一個就是InvocationHandler接口，這個方法中的invoke方法是執行代理時會執行的方法。所以我們所有代理需要執行的邏輯都會寫在這里面,invo參數里面的method可以使用java 反射調用真實的實現類的方法，我們在這個方法周圍做一些代理邏輯工作就可以了。上面的代碼會把Calculator接口的所有方法全部在程序運行時代理。不用我們一個個的去寫靜態代理的方法。
JDK動態代理的原理
先看Proxy.newProxyInstance(...)方法中的具體實現(省略大部分方法)。在下面的代碼中會通過getProxyClass0(...)方法得到class對象，然后給把InvocationHandler已構造參數實例化代理對象。思路還是挺清晰的,但是如果要一探究竟我們還是得知道代理對象到底是什么樣的，如何實現的代理呢？
public static Object newProxyInstance(ClassLoader loader,Class<?>[] interfaces,InvocationHandler h)throws IllegalArgumentException
{
//......
/*
*得到代理的對象的class對象。
*/
Class<?> cl = getProxyClass0(loader, intfs);
/*
* 給class 對象構造函數傳入InvocationHandler 實例化對象
*/
//.....
return newInstance(cons, ih);
//....
}
在getProxyClass0（..）方法中有下面這段代碼.顧名思義這段代碼應該是對代理的字節碼做了緩存.這是顯而易見的，我們不會每次調用都去生成代理對象。需要對代理對象緩存。我們發現緩存是用的一個叫WeakCache的類。我們不探究這個類具體的工作是怎樣的，我們只需要看我們的字節碼是如何生成的.注釋中ProxyClassFactory這個類應該是我們需要尋找的類。
// 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中下面的方法可以看到具體生成字節流的方法是ProxyGenerator.generateProxyClass(..).最后通過native方法生成Class對象。同時對class對象的包名稱有一些規定比如命名為com.meituan.Utils$proxy0。要想得到字節碼實例我們需要先下載這部分字節流,然后通過反編譯得到java代碼。
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` 前綴默認是包名稱加$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(..)方法生成字節流，然后寫進硬盤.假設我把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文件。 當然也可以實現在線反編譯http://javare.cn/網站反編譯然后下載文件
public static void main(String[] args) {
//傳入Calculator接口
ProxyUtils.generateClassFile(Calculator.class,"Calcultor$ProxyCode");
}
public static void generateClassFile(Class clazz,String proxyName)
{
//根據類信息和提供的代理類名稱，生成字節碼
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類?？梢园l現這個類實現了我們需要代理的接口Calculator。且他的構造函數確實是需要傳遞一個InvocationHandler對象,那么現在的情況就是我們的生成了一個代理類,這個代理類是我們需要代理的接口的實現類。我們的接口中定義了add和reduce方法,在這個代理類中幫我們實現了，并且全部變成了final的。同時覆蓋了一些Object類中的方法。那我們現在以reduce這個方法舉例,方法中會調用InvocationHandler類中的invoke方法(也就是我們實現的邏輯的地方)。同時把自己的Method對象，參數列表等傳入進去。
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靜態塊加載每個方法的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動態代理小結
現在我們對JDK代理有個簡單的源碼級別的認識,理清楚一下思路:JDK會幫我們在運行時生成一個代理類,這個代理類實際上就是我們需要代理的接口的實現類。實現的方法里面會調用InvocationHandler類中的invoke方法,并且同時傳入自身被調用的方法的的Method對象和參數列表方便我們編碼實現方法的調用。比如我們調用reduce方法，那么我們就可以通過Method.Invoke(Object obj, Object... args)調用我們具體的實現類,再在周圍做一些代理做的事兒。就實現了動態代理。我們對JDK的特性做一些簡單的認識：
- JDK動態代理只能代理有接口的類,并且是能代理接口方法,不能代理一般的類中的方法
- 提供了一個使用InvocationHandler作為參數的構造方法。在代理類中做一層包裝,業務邏輯在invoke方法中實現
- 重寫了Object類的equals、hashCode、toString，它們都只是簡單的調用了InvocationHandler的invoke方法，即可以對其進行特殊的操作，也就是說JDK的動態代理還可以代理上述三個方法
- 在invoke方法中我們甚至可以不用Method.invoke方法調用實現類就返回。這種方式常常用在RPC框架中,在invoke方法中發起通信調用遠端的接口等
CGLIB代理
JDK中提供的生成動態代理類的機制有個鮮明的特點是：某個類必須有實現的接口，而生成的代理類也只能代理某個類接口定義的方法。那么如果一個類沒有實現接口怎么辦呢？這就有CGLIB的誕生了,前面說的JDK的代理類的實現方式是實現相關的接口成為接口的實現類,那么我們自然而然的可以想到用繼承的方式實現相關的代理類。CGLIB就是這樣做的。一個簡單的CGLIB代理是這樣實現的:
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代理原理分析
通過在執行動態代理的代碼前面加上一行代碼就可以得到生成的代理對象.代理對象的class文件會生成在你定義的路徑下。類似Calculator$CalculatorImpl$$EnhancerByCGLIB$$58419779.class這樣結構。
System.setProperty(DebuggingClassWriter.DEBUG_LOCATION_PROPERTY, "${your path}");之后我們通過反編譯得到反編譯后的java文件。就上面的例子而言我們傳入的superclass是一個接口，并不是實現類。那我們得到的代理類會長成這樣:
//如果是接口代理類還是通過實現接口的方式
public class Calculator$$EnhancerByCGLIB$$40fd3cad implements Calculator, Factory{
//...
}
如果傳入的并不是接口，而是實現類的話，就會得到下面的代理類:
//如果是普通的類，會采用繼承的方式實現
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});
}
//非接口中的方法，在實現類中定義的
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的方法會額外實現一個和原方法一模一樣的方法
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) {
//調用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;
}
//調用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 根據實現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();
}
}
上面這一份代碼整個代理的流程仿佛是差不多的，都是在調用方法的時候router到InvokeHandler或者MethodInterceptor。為什么會有兩種呢，因為CGLIB提供了filter的機制，可以讓不同的方法代理到不同的callback中,如下面這樣:
enhancer.setCallbacks(new Callback[]{new MethodInterceptor() {
//...
},new InvocationHandler() {
//...
}});
enhancer.setCallbackFilter(new CallbackFilter() {
@Override
public int accept(Method method) {
//返回的下標和在Callback數組中的下標對應,下面表達的是reduce方法綁定MethodInterceptor
if(method.getName().equals("reduce")) return 1;
return 0;
}
});
這兩種callback不一樣的地方很顯而易見, MethodInterceptor的方法參數多了一個MethodProxy對象，在使用這個對象的時候的時候有兩個方法可以讓我們調用:
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實現的一種通過給方法建立下標索引來訪問方法的策略，為了繞開反射。 上面的描述代表MethodPeoxy可以根據對方法建立索引調用方法，而不需要使用傳統Method的invoke反射調用，提高了性能，當然額外的得多生成一些類信息,比如在最開始的代理類中我們也可以看到MethodProxy也是有通過索引來做的，這樣的話做到了FastClass,FastClass大致是這樣實現的:
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){
//根據index調用方法，
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;
}
實際上調用的就是綁定了MethodInterceptor callback接口然后在代理類中額外生成的類如上面所標注的final int CGLIB$reduce$2(int var1, int var2)?方便MethodProxy調用，但有個前提是你傳入的superclass不能是接口,super.xxx(*)會調用失敗，會拋出NoSuchMethodError錯誤。
小結
- CGlib可以傳入接口也可以傳入普通的類，接口使用實現的方式,普通類使用會使用繼承的方式生成代理類.
- 由于是繼承方式,如果是 static方法,private方法,final方法等描述的方法是不能被代理的
- 做了方法訪問優化，使用建立方法索引的方式避免了傳統Method的方法反射調用.
- 提供callback 和filter設計，可以靈活地給不同的方法綁定不同的callback。編碼更方便靈活。
- CGLIB會默認代理Object中finalize,equals,toString,hashCode,clone等方法。比JDK代理多了finalize和clone。
AspectJ靜態編譯織入
前面兩種都是說的在代碼運行時動態的生成class文件達到動態代理的目的，那我們現在回到靜態代理，靜態代理唯一的缺點就是我們需要對每一個方法編寫我們的代理邏輯，造成了工作的繁瑣和復雜。AspectJ就是為了解決這個問題，在編譯成class字節碼的時候在方法周圍加上業務邏輯。復雜的工作由特定的編譯器幫我們做。
AOP有切面(Aspect)、連接點(joinpoint)、通知(advice)、切入點(Pointcut)、目標對象(target)等概念,這里不詳細介紹這些概念.
如何做ASpectj開發,這里使用的是maven插件,詳細使用文檔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?此文章：
//表示對實現了Mtrace接口的類，并且參數數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) {
//方法調用前植入
System.out.println("=========BEFORE=========");
}
@After("zhiru2()")//后面植入
public void after(JoinPoint point) {
//方法調用后植入
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文件之后，編譯代碼就能夠得到靜態織入的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 {
//調用before
Aspectj.aspectOf().doBeforeTask2(var2);
System.out.println(name);
Util.report("xiezhaodong");
var5 = null;
} catch (Throwable var8) {
Aspectj.aspectOf().after(var2);
throw var8;
}
//調用after
Aspectj.aspectOf().after(var2);
var7 = var5;
} catch (Throwable var9) {
//調用拋出異常
Aspectj.aspectOf().afterthrowing(var2);
throw var9;
}
//調用return
Aspectj.aspectOf().afterRutuen(var2);
return (ModelAndView)var7;
}
@RequestMapping({"/hello2"})
public ModelAndView helloMyMethodName222(String name) throws SQLException {
return new ModelAndView("hello", "name", name);
}
上面兩個方法都實現了@ RequestMapping注解,類也實現類Mtrace接口。但是因為傳入參數的類型不同，所以只有第一個方法被織入了代理的方法,在真正的方法快周圍分表調用了before、after、afterThrowing、afterRutnrn等方法。Aspectj簡單的原理就是這樣.更加深入的原理解析暫時就不做了。
小結
- Aspectj并不是動態的在運行時生成代理類，而是在編譯的時候就植入代碼到class文件
- 由于是靜態織入的，所以性能相對來說比較好
- Aspectj不受類的特殊限制,不管方法是private、或者static、或者final的,都可以代理
- Aspectj不會代理除了限定方法之外任何其他諸如toString(),clone()等方法
Spring Aop中的代理
Spring代理實際上是對JDK代理和CGLIB代理做了一層封裝，并且引入了AOP概念:Aspect、advice、joinpoint等等，同時引入了AspectJ中的一些注解@pointCut,@after,@before等等.Spring Aop嚴格的來說都是動態代理，所以實際上Spring代理和Aspectj的關系并不大.
Spring代理中org.springframework.aop.framework.ProxyFactory是關鍵,一個簡單的使用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();
在調用getProxy()時，會優先得到一個默認的DefaultAopProxyFactory.這個類主要是決定到底是使用JDK代理還是CGLIB代理:
public AopProxy createAopProxy(AdvisedSupport config) throws AopConfigException {
//optimize 優化，如上列代碼編程true會默認進入if
//ProxyTargetClass 是否對具體類進行代理
//判斷傳入的class 是否有接口。如果沒有也會進入選擇
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.");
}
//如果目標是接口的話還是默認使用JDK
if (targetClass.isInterface()) {
return new JdkDynamicAopProxy(config);
}
return CglibProxyFactory.createCglibProxy(config);
}
else {
return new JdkDynamicAopProxy(config);
}
}
可以看見一些必要的信息，我們在使用Spring AOP的時候通常會在XML配置文件中設置<aop:aspectj-autoproxy proxy-target-class="true">?來使用CGlib代理。現在我們可以發現只要三個參數其中一個為true，便可以有機會選擇使用CGLIB代理。但是是否一定會使用還是得看傳入的class到底是個怎樣的類。如果是接口，就算開啟了這幾個開關，最后還是會自動選擇JDK代理。
JdkDynamicAopProxy這個類實現了InvokeHandler接口，最后調用getProxy():
public Object getProxy(ClassLoader classLoader) {
//...
//返回代理對象
return Proxy.newProxyInstance(classLoader, proxiedInterfaces, this);
}
那么JdkDynamicAopProxy中的invoke方法就是最核心的方法了(實現了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 {
//是否實現equals和hashCode，否則不代理。因為JDK代理會默認代理這兩個方法
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得到一個實例對象，可實現接口獲得
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.
//如果沒有定義攔截器鏈。直接調用方法不進行代理
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遞歸調用
// 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()方法負責遞歸調用所有的攔截的織入。
public Object proceed() throws Throwable {
//list的索引從-1開始。
if (this.currentInterceptorIndex == this.interceptorsAndDynamicMethodMatchers.size() - 1) {
//所有interceptor都被執行完了，直接執行原方法
return invokeJoinpoint();
}
//得到一個interceptor。不管是before還是after等織入，都不受在list中的位置影響。
Object interceptorOrInterceptionAdvice =
this.interceptorsAndDynamicMethodMatchers.get(++this.currentInterceptorIndex);
//....
//調用invoke方法
return ((MethodInterceptor) interceptorOrInterceptionAdvice).invoke(this);
}
}
需要注意的是invoke方法中傳入的是this。在MethodInvocation中又可以調用procced來實現遞歸調用。比如像下面這樣:
new MethodInterceptor() {
@Override
public Object invoke(MethodInvocation invocation) throws Throwable {
Object re= invocation.proceed();
return re;
}
}
那么要實現織入，只需要控制織入的代碼和調用proceed方法的位置，在Spring中的before織入是這樣實現的:
public class MethodBeforeAdviceInterceptor implements MethodInterceptor, Serializable {
private MethodBeforeAdvice advice;
public Object invoke(MethodInvocation mi) throws Throwable {
//調用before實際代碼
this.advice.before(mi.getMethod(), mi.getArguments(), mi.getThis() );
//繼續迭代
return mi.proceed();
}
afterRuturning是這樣實現的:
public class AfterReturningAdviceInterceptor implements MethodInterceptor, AfterAdvice, Serializable {
private final AfterReturningAdvice advice;
public Object invoke(MethodInvocation mi) throws Throwable {
Object retVal = mi.proceed();
//只要控制和mi.proceed()調用的位置關系就可以實現任何狀態的織入效果
this.advice.afterReturning(retVal, mi.getMethod(), mi.getArguments(), mi.getThis());
return retVal;
}
下面這幅流程圖是一個一個包含上述一個before織入和一個afterReturning織入的流程圖:
?
要實現這種環繞的模式其實很簡單，下面提供一個最簡單的實現，利用迭代的思想很簡單的實現了鏈式調用。并且可擴展性非常高。和AspectJ的直接靜態織入改變代碼結構的方式來分別織入before、after等來說。這種方式設計更優雅。但是在SpringMVC中攔截器卻并不是這種方式實現的，哈哈。
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("執行方法實體");
return "返回值";
}
MethodInterceptor methodInterceptor = list.get(++index);
return methodInterceptor.invoke(this);
}
}
}
小結
Spring AOP封裝了JDK和CGLIB的動態代理實現，同時引入了AspectJ的編程方式和注解。使得可以使用標準的AOP編程規范來編寫代碼外，還提供了多種代理方式選擇?？梢愿鶕枨髞磉x擇最合適的代理模式。同時Spring也提供了XML配置的方式實現AOP配置。可以說是把所有想要的都做出來了，Spring是在平時編程中使用動態代理的不二選擇.
總結
以上是生活随笔為你收集整理的Java JDK代理、CGLIB、AspectJ代理分析比较的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 浅谈推荐系统基础
- 下一篇： Java多线程（七）之同步器基础：AQS