上篇文章我們學習瞭如何自己實現一個動態代理,這篇文章我們從源碼角度來分析下JDK的動態代理
先看一個Demo:
public class MyInvocationHandler implements InvocationHandler {
private MyService target;
public MyInvocationHandler(MyService target) {
this.target = target;
}
@Override
public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {
Object invoke = method.invoke(target, args);
System.out.println("proxy invoke");
if (method.getReturnType().equals(Void.TYPE)) {
return null;
} else {
System.out.println(invoke);
return invoke+"proxy";
}
}
}
public interface MyService {
void test01();
void test02(String s);
}
public class MyServiceImpl implements MyService {
@Override
public void test01() {
System.out.println("test01");
}
@Override
public void test02(String s) {
System.out.println(s);
}
}
main方法:
public class Main {
public static void main(String[] args) {
MyServiceImpl target = new MyServiceImpl();
Class<? extends MyServiceImpl> clazz = target.getClass();
MyService proxyInstance = (MyService) Proxy.newProxyInstance(clazz.getClassLoader(), clazz.getInterfaces()
, new MyInvocationHandler(target));
proxyInstance.test01();
proxyInstance.test02("test02");
}
}
我們運行Debug觀察下生成的proxyInstance
對象:
可以得出以下幾個結論:
- 生成的代理類的類名是
$Proxy0
- 代理類持有我們的
MyInvocationHandler
對象
這裏我們越過不重要的代碼,直接端點到java.lang.reflect.Proxy.ProxyClassFactory#apply
這個方法,
我們分段分析這個方法的代碼(簡單的代碼我們就直接跳過了):
Class<?> interfaceClass = null;
try {
interfaceClass = Class.forName(intf.getName(), false, loader);
} catch (ClassNotFoundException e) {
}
if (interfaceClass != intf) {
throw new IllegalArgumentException(
intf + " is not visible from class loader");
}
這段代碼主要是爲了確保類加載器對這個class文件解析後得到的是同一個對象。如果我們要確保兩個對象相等的話,那麼它們的類加載器必定是一樣的。
for (Class<?> intf : interfaces) {
int flags = intf.getModifiers();
if (!Modifier.isPublic(flags)) {
accessFlags = Modifier.FINAL;
String name = intf.getName();
int n = name.lastIndexOf('.');
String pkg = ((n == -1) ? "" : name.substring(0, n + 1));
if (proxyPkg == null) {
proxyPkg = pkg;
} else if (!pkg.equals(proxyPkg)) {
throw new IllegalArgumentException(
"non-public interfaces from different packages");
}
}
}
if (proxyPkg == null) {
// if no non-public proxy interfaces, use com.sun.proxy package
proxyPkg = ReflectUtil.PROXY_PACKAGE + ".";
}
這段代碼主要是在判斷接口是否是public的,如果不是public的那麼需要將代理類生成在接口同名的包下。否則生成的代理類在com.sun.proxy
包下。
這裏我們可以做一個驗證:
- 我們測試接口如果不是public的,代理類會生成在接口的同一個包下,在這種情況下,我們可以在接口的同名包下新建一個類,類名爲
$Proxy0
,如下:
// 接口換爲包訪問權限
interface MyService {
void test01();
void test02(String s);
}
新建一個類,類名爲$Proxy0
- main函數進行測試
public static void main(String[] args) {
MyServiceImpl target = new MyServiceImpl();
Class<? extends MyServiceImpl> clazz = target.getClass();
// 加載這個類到JVM中
$Proxy0 proxy0 = new $Proxy0();
MyService proxyInstance = (MyService) Proxy.newProxyInstance(clazz.getClassLoader(), clazz.getInterfaces()
, new MyInvocationHandler(target));
proxyInstance.test01();
proxyInstance.test02("test02");
}
運行後發現報錯:顯示有重複的類定義
Exception in thread "main" java.lang.LinkageError: loader (instance of sun/misc/Launcher$AppClassLoader): attempted duplicate class definition for name: "com/dmz/proxy/target/$Proxy0"
at java.lang.reflect.Proxy.defineClass0(Native Method)
at java.lang.reflect.Proxy.access$300(Proxy.java:228)
at java.lang.reflect.Proxy$ProxyClassFactory.apply(Proxy.java:642)
at java.lang.reflect.Proxy$ProxyClassFactory.apply(Proxy.java:557)
at java.lang.reflect.WeakCache$Factory.get(WeakCache.java:230)
at java.lang.reflect.WeakCache.get(WeakCache.java:127)
at java.lang.reflect.Proxy.getProxyClass0(Proxy.java:419)
at java.lang.reflect.Proxy.newProxyInstance(Proxy.java:719)
at com.dmz.proxy.target.Main.main(Main.java:14)
從上面我們就驗證了,如果不是public的那麼需要將代理類生成在接口同名的包下
接下來我們驗證,正常情況下,代理類會被生成在com.sun.proxy
包下
- 同理,我們可以創建一個類,全類名爲
com.sun.proxy.$Proxy0
- 同時我們將接口改爲public的,同樣的我們會發現會報同一個錯。
至此,證明完畢。我們繼續看代碼
byte[] proxyClassFile = ProxyGenerator.generateProxyClass(
proxyName, interfaces, accessFlags);
try {
return defineClass0(loader, proxyName,
proxyClassFile, 0, proxyClassFile.length);
// 省略部分代碼......
我們可以看到,通過ProxyGenerator.generateProxyClass(proxyName, interfaces, accessFlags)
生成一個字節流後,直接調用了defineClass0(…)方法,而且我們跟蹤這個方法可以發現,這是一個本地方法。並且它直接返回了一個Class對象。
private static native Class<?> defineClass0(ClassLoader loader, String name,
byte[] b, int off, int len);
回顧我們上一篇文章的實現思路:
對比後我們可以發現,我們自己實現時,是通過生成java文件,然後進行編譯生成class文件,再將其加載到JVM中得到class對象。而對於jdk動態代理,直接通過一個字節流調用本地方法後直接生成class對象。
我們再回過頭去看下jdk是如何給我們生成這個字節流的,這裏我們主要關注sun.misc.ProxyGenerator#generateClassFile
這個方法,這裏我就不貼代碼了。因爲也是一些字符串的拼接動作,然後寫入到一個字節流中,我們關注下最後生成的這個字節流是什麼樣子的,我們將其寫入到一個文件中:
MyServiceImpl target = new MyServiceImpl();
Class<? extends MyServiceImpl> clazz = target.getClass();
MyService proxyInstance = (MyService) Proxy.newProxyInstance(clazz.getClassLoader(), clazz.getInterfaces()
, new MyInvocationHandler(target));
byte[] bytes = ProxyGenerator.generateProxyClass("proxy", clazz.getInterfaces());
File file = new File("G:\\com\\dmz\\proxy\\proxy.class");
FileOutputStream outputStream = new FileOutputStream(file);
outputStream.write(bytes);
proxyInstance.test01();
proxyInstance.test02("test02");
我們將得到的這個class文件放入idea反編譯:
public final class proxy extends Proxy implements MyService {
private static Method m1;
private static Method m4;
private static Method m2;
private static Method m3;
private static Method m0;
public proxy(InvocationHandler var1) throws {
super(var1);
}
public final boolean equals(Object var1) throws {
try {
return (Boolean)super.h.invoke(this, m1, new Object[]{var1});
} catch (RuntimeException | Error var3) {
throw var3;
} catch (Throwable var4) {
throw new UndeclaredThrowableException(var4);
}
}
public final void test01() throws {
try {
super.h.invoke(this, m4, (Object[])null);
} catch (RuntimeException | Error var2) {
throw var2;
} catch (Throwable var3) {
throw new UndeclaredThrowableException(var3);
}
}
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);
}
}
public final void test02(String var1) throws {
try {
super.h.invoke(this, m3, new Object[]{var1});
} catch (RuntimeException | Error var3) {
throw var3;
} catch (Throwable var4) {
throw new UndeclaredThrowableException(var4);
}
}
public final int hashCode() throws {
try {
return (Integer)super.h.invoke(this, m0, (Object[])null);
} catch (RuntimeException | Error var2) {
throw var2;
} catch (Throwable var3) {
throw new UndeclaredThrowableException(var3);
}
}
static {
try {
m1 = Class.forName("java.lang.Object").getMethod("equals", Class.forName("java.lang.Object"));
m4 = Class.forName("com.dmz.proxy.target.MyService").getMethod("test01");
m2 = Class.forName("java.lang.Object").getMethod("toString");
m3 = Class.forName("com.dmz.proxy.target.MyService").getMethod("test02", Class.forName("java.lang.String"));
m0 = Class.forName("java.lang.Object").getMethod("hashCode");
} catch (NoSuchMethodException var2) {
throw new NoSuchMethodError(var2.getMessage());
} catch (ClassNotFoundException var3) {
throw new NoClassDefFoundError(var3.getMessage());
}
}
}
觀察上面代碼,我們可以發現以下幾點:
-
代理類繼承了
Proxy
這個類,正因爲如此,所以jdk動態代理只能實現基於接口的代理,而不能實現對整個類進行代理,因爲java是單繼承的。那麼爲什麼代理類一定要繼承Proxy
這個類呢?我們可以發現代理類並沒有使用Proxy
中的什麼屬性或者方法(雖然使用了InvocationHandler對象,但是也可以在生成class之初就將InvocationHandler放入到代理類中)。所以實際上不進行繼承也是沒有任何關係的。查了很多資料後發現,找到一個比較合理的解釋如下:JDK的動態代理只允許動態代理接口是設計使然,因爲動態代理一個類存在一些問題。在代理模式中代理類只做一些額外的攔截處理,實際處理是轉發到原始類做的。這裏存在兩個對象,代理對象跟原始對象。如果允許動態代理一個類,那麼代理對象也會繼承類的字段,而這些字段是實際上是沒有使用的,對內存空間是一個浪費。因爲代理對象只做轉發處理,對象的字段存取都是在原始對象上處理。更爲致命的是如果代理的類中有final的方法,動態生成的類是沒法覆蓋這個方法的,沒法代理,而且存取的字段是代理對象上的字段,這顯然不是我們希望的結果。spring aop框架就是這種模式。
總結起來主要兩點
-
我們在進行代理時,實際的方法執行邏輯仍然是交給目標類處理,這個時候代理類持有目標類中的字段只不過是對內存空間的一種浪費,其餘沒有任何作用。
-
即使我們能接受對內存空間的浪費,然而如果我們在代理對象中操作代理對象中的字段,目標對象的字段不受任何影響,這顯然也是不合理的。
-
如果是基於繼承實現代理,那麼有final的方法的情況下,無法完成對final方法的代理。
-
-
代理類實現了我們目標對象實現的接口,所以說JDK動態代理是基於接口實現的。
-
代理對象不僅僅是對接口中的方法進行了代理,還對hashCode,equals,toString三個方法進行了代理,這也是爲了覆蓋目標類中的所有方法
至此,我們就完成對JDK動態代理的學習!喜歡的同學點個贊吧~~~~