反射真的慢麼？動態代理會建立不少臨時class?
公衆號：內核小王子java
問題
- 1.反射真的慢麼？
- 2.動態代理會建立不少臨時class?
- 3.屬性經過反射讀取怎麼實現的？
當咱們在IDE中編寫代碼的時候，打一個點號，IDE會自動彈出對應的屬性和方法名，當咱們在debug的時候，IDE會將方法運行時方法內局部變量和外部實例上屬性的值都展現出來，spring中的IOC和AOP，以及一個RPC框架中，咱們反序列化，consumer的代理，以及provider的調用都會用到java的反射功能，有人說使用反射會慢，那麼到底慢在哪裏呢？面試
反射
反射使JAVA語言有了動態編譯的功能，也就是在咱們編碼的時候不須要知道對象的具體類型，可是在運行期能夠經過Class.forName()獲取一個類的class對象,在經過newInstance獲取實例。spring
先看下java.lang.reflect包下的幾個主要類的關係圖，固然動態代理的工具類也在該包下。json
- AnnotatedElement
做爲頂級接口，這個接口提供了獲取註解相關的功能，咱們在方法，類，屬性，構造方法上均可以加註解，因此下面的Field，Method，Constructor都有實現這個接口，如下是咱們常常用的兩個方法，jdk8之後,接口裏面能夠經過default修飾方法實現了數組
Annotation[] getAnnotations(); //獲取目標對象(方法和屬性)上的全部註解
default <T extends Annotation> T getDeclaredAnnotation(Class<T> annotationClass) {
Objects.requireNonNull(annotationClass);
// Loop over all directly-present annotations looking for a matching one
for (Annotation annotation : getDeclaredAnnotations()) {
if (annotationClass.equals(annotation.annotationType())) {
// More robust to do a dynamic cast at runtime instead
// of compile-time only.
return annotationClass.cast(annotation);
}
}
return null;
}
- GenericDeclaration
提供了獲取泛型相關的功能，只有方法和構造方法上支持泛型，因此只有Method，Constructor實現了該接口緩存
- Member
做爲一個對象內部方法和屬性的聲明的抽象，包含了名稱，修飾符，所在的類,其中修飾符包含了 static final public private volatile 等，經過一個整數表示，每個類型在二進制中佔一個位.網絡
public Class<?> getDeclaringClass();
public String getName();
public int getModifiers();
如下爲Modifier類部分代碼
public static final int PUBLIC = 0x00000001;
public static final int PRIVATE = 0x00000002;
public static final int PROTECTED = 0x00000004;
public static final int STATIC = 0x00000008;
public static final int FINAL = 0x00000010;
public static final int SYNCHRONIZED = 0x00000020;
public static final int VOLATILE = 0x00000040;
public static final int TRANSIENT = 0x00000080;
public static final int NATIVE = 0x00000100;
public static final int INTERFACE = 0x00000200;
public static final int ABSTRACT = 0x00000400;
public static final int STRICT = 0x00000800;
public static boolean isPublic(int mod) {
return (mod & PUBLIC) != 0;
}
-
AccessibleObject負載均衡
這是一個類，提供了權限管理的功能，例如是否容許在反射中在外部調用一個private方法，獲取一個private屬性的值，因此method，constructor,field都繼承該類，下面這段代碼展現瞭如何在反射中訪問一個私有的成員變量，class對象的構造方法不容許對外.框架
private static void setAccessible0(AccessibleObject obj, boolean flag)
throws SecurityException
{
if (obj instanceof Constructor && flag == true) {
Constructor<?> c = (Constructor<?>)obj;
if (c.getDeclaringClass() == Class.class) {
throw new SecurityException("Cannot make a java.lang.Class" +
" constructor accessible");
}
}
obj.override = flag;
}
boolean override;
public boolean isAccessible() {
return override;
}
如下爲 Field裏面經過field.get(原始對象)獲取屬性值得實現,先經過override作校驗，若是沒有重載該權限，則須要校驗訪問權限ide
public Object get(Object obj)
throws IllegalArgumentException, IllegalAccessException
{
if (!override) {
if (!Reflection.quickCheckMemberAccess(clazz, modifiers)) {
Class<?> caller = Reflection.getCallerClass();
checkAccess(caller, clazz, obj, modifiers);
}
}
return getFieldAccessor(obj).get(obj);
}
下面咱們看看如何經過反射修改Field裏面屬性的值
經過上面的代碼，咱們能夠看出jdk將Field屬性的讀取和寫入委託給FieldAccessor，那麼如何獲取FieldAccessor呢
class UnsafeFieldAccessorFactory {
UnsafeFieldAccessorFactory() {
}
static FieldAccessor newFieldAccessor(Field var0, boolean var1) {
Class var2 = var0.getType();
boolean var3 = Modifier.isStatic(var0.getModifiers());
boolean var4 = Modifier.isFinal(var0.getModifiers());
boolean var5 = Modifier.isVolatile(var0.getModifiers());
boolean var6 = var4 || var5;
boolean var7 = var4 && (var3 || !var1);
if (var3) {
UnsafeFieldAccessorImpl.unsafe.ensureClassInitialized(var0.getDeclaringClass());
return (FieldAccessor) ((!var6)
? ((var2 == Boolean.TYPE)
? new UnsafeStaticBooleanFieldAccessorImpl(var0)
: ((var2 == Byte.TYPE)
? new UnsafeStaticByteFieldAccessorImpl(var0)
: ((var2 == Short.TYPE)
? new UnsafeStaticShortFieldAccessorImpl(var0)
: ((var2 == Character.TYPE)
? new UnsafeStaticCharacterFieldAccessorImpl(var0)
: ((var2 == Integer.TYPE)
? new UnsafeStaticIntegerFieldAccessorImpl(var0)
: ((var2 == Long.TYPE)
? new UnsafeStaticLongFieldAccessorImpl(var0)
: ((var2 == Float.TYPE)
? new UnsafeStaticFloatFieldAccessorImpl(var0)
: ((var2 == Double.TYPE)
? new UnsafeStaticDoubleFieldAccessorImpl(var0)
: new UnsafeStaticObjectFieldAccessorImpl(var0)))))))))
: ((var2 == Boolean.TYPE)
? new UnsafeQualifiedStaticBooleanFieldAccessorImpl(var0, var7)
: ((var2 == Byte.TYPE)
? new UnsafeQualifiedStaticByteFieldAccessorImpl(var0, var7)
: ((var2 == Short.TYPE)
? new UnsafeQualifiedStaticShortFieldAccessorImpl(var0, var7)
: ((var2 == Character.TYPE)
? new UnsafeQualifiedStaticCharacterFieldAccessorImpl(var0, var7)
: ((var2 == Integer.TYPE)
? new UnsafeQualifiedStaticIntegerFieldAccessorImpl(var0, var7)
: ((var2 == Long.TYPE)
? new UnsafeQualifiedStaticLongFieldAccessorImpl(var0, var7)
: ((var2 == Float.TYPE)
? new UnsafeQualifiedStaticFloatFieldAccessorImpl(var0, var7)
: ((var2 == Double.TYPE)
? new UnsafeQualifiedStaticDoubleFieldAccessorImpl(var0, var7)
: new UnsafeQualifiedStaticObjectFieldAccessorImpl(var0, var7))))))))));
} else {
return (FieldAccessor) ((!var6)
? ((var2 == Boolean.TYPE)
? new UnsafeBooleanFieldAccessorImpl(var0)
: ((var2 == Byte.TYPE) ? new UnsafeByteFieldAccessorImpl(var0)
: ((var2 == Short.TYPE)
? new UnsafeShortFieldAccessorImpl(var0)
: ((var2 == Character.TYPE)
? new UnsafeCharacterFieldAccessorImpl(var0)
: ((var2 == Integer.TYPE)
? new UnsafeIntegerFieldAccessorImpl(var0)
: ((var2 == Long.TYPE) ? new UnsafeLongFieldAccessorImpl(var0)
: ((var2 == Float.TYPE)
? new UnsafeFloatFieldAccessorImpl(var0)
: ((var2 == Double.TYPE) ? new UnsafeDoubleFieldAccessorImpl(var0)
: new UnsafeObjectFieldAccessorImpl(var0)))))))))
: ((var2 == Boolean.TYPE)
? new UnsafeQualifiedBooleanFieldAccessorImpl(var0, var7)
: ((var2 == Byte.TYPE)
? new UnsafeQualifiedByteFieldAccessorImpl(var0, var7)
: ((var2 == Short.TYPE)
? new UnsafeQualifiedShortFieldAccessorImpl(var0, var7)
: ((var2 == Character.TYPE)
? new UnsafeQualifiedCharacterFieldAccessorImpl(var0, var7)
: ((var2 == Integer.TYPE)
? new UnsafeQualifiedIntegerFieldAccessorImpl(var0, var7)
: ((var2 == Long.TYPE)
? new UnsafeQualifiedLongFieldAccessorImpl(var0, var7)
: ((var2 == Float.TYPE)
? new UnsafeQualifiedFloatFieldAccessorImpl(var0, var7)
: ((var2 == Double.TYPE)
? new UnsafeQualifiedDoubleFieldAccessorImpl(var0, var7)
: new UnsafeQualifiedObjectFieldAccessorImpl(var0, var7))))))))));
}
}
}
以上代碼能夠發現，經過工廠模式根據field屬性類型以及是否靜態來獲取，爲何會有這樣的劃分呢
首先，jdk是經過UNSAFE類對堆內存中對象的屬性進行直接的讀取和寫入，要讀取和寫入首先須要肯定屬性所在的位置，也就是相對對象起始位置的偏移量，而靜態屬性是針對類的不是每一個對象實例一份，因此靜態屬性的偏移量須要單獨獲取
其實經過該偏移量咱們能夠大體推斷出一個實例內每一個屬性在堆內存的相對位置，以及分別佔用多大的空間，有了位置信息，咱們還須要這個字段的類型，以方便執行器知道讀幾個字節的數據，而且如何進行解析，目前提供了8大基礎類型（char vs Charector）和數組和普通引用類型。 java虛擬機爲了保證每一個對象所佔的空間都是8個字節倍數,有時候爲了不兩個volatile字段存放在同一個緩存行,因此有時候會再某些字段上作空位填充
如下爲UnSafe類的部分代碼
public final class Unsafe {
private static final Unsafe theUnsafe;
private Unsafe() {
}
@CallerSensitive
public static Unsafe getUnsafe() {
Class var0 = Reflection.getCallerClass();
if(!VM.isSystemDomainLoader(var0.getClassLoader())) {
throw new SecurityException("Unsafe");
} else {
return theUnsafe;
}
}
public native int getInt(Object var1, long var2);
public native void putInt(Object var1, long var2, int var4);
public native Object getObject(Object var1, long var2);
public native void putObject(Object var1, long var2, Object var4);
public native boolean getBoolean(Object var1, long var2);
public native void putBoolean(Object var1, long var2, boolean var4);
public native byte getByte(Object var1, long var2);
public native long objectFieldOffset(Field var1);
@Deprecated
public int fieldOffset(Field var1) {
return Modifier.isStatic(var1.getModifiers())?(int)this.staticFieldOffset(var1):(int)this.objectFieldOffset(var1);
}
而後咱們在來看看經過反射來調用方法
一樣，jdk經過MethodAccessor來進行method的調用，java虛擬機提供了兩種模式來支持method的調用 一個是NativeMethodAccessorImpl 一個是經過ASM字節碼直接動態生成一個類在invoke方法內部調用目標方法，因爲是動態生成因此jdk中沒有其源碼，但jdk提供了DelegatingMethodAccessorImpl委派模式以方便在運行過程當中能夠動態切換字節碼模式和native模式，咱們能夠看下生成MethodAccessor的代碼
class NativeMethodAccessorImpl extends MethodAccessorImpl {
private final Method method;
private DelegatingMethodAccessorImpl parent;
private int numInvocations;
NativeMethodAccessorImpl(Method var1) {
this.method = var1;
}
public Object invoke(Object var1, Object[] var2) throws IllegalArgumentException, InvocationTargetException {
if(++this.numInvocations > ReflectionFactory.inflationThreshold() && !ReflectUtil.isVMAnonymousClass(this.method.getDeclaringClass())) {
MethodAccessorImpl var3 = (MethodAccessorImpl)(new MethodAccessorGenerator()).generateMethod(this.method.getDeclaringClass(), this.method.getName(), this.method.getParameterTypes(), this.method.getReturnType(), this.method.getExceptionTypes(), this.method.getModifiers());
this.parent.setDelegate(var3);
}
return invoke0(this.method, var1, var2);
}
void setParent(DelegatingMethodAccessorImpl var1) {
this.parent = var1;
}
private static native Object invoke0(Method var0, Object var1, Object[] var2);
}
能夠看到JDK內部經過numInvocations判斷若是該反射調用次數超過ReflectionFactory.inflationThreshold()則用字節碼實現，若是小於該值則採用native實現，native的調用比字節碼方式慢不少， 動態實現和本地實現相比執行效率要快20倍，由於動態實現無需通過JAVA,C++再到JAVA的轉換，以前在jdk6之前有個工具ReflectAsm就是採用這種方式提高執行效率，不過在jdk8之後，也提供了字節碼方式，因爲許多反射只須要執行一次，然而動態方式生成字節碼十分耗時，因此jdk提供了一個閾值默認15，當某個反射的調用次數小於15的話就走本地實現，大於15則走動態模式，而這個閾值能夠在jdk啓動參數裏面作配置
反射爲何慢
通過以上優化，其實反射的效率並不慢，在某些狀況下可能達到和直接調用基本相同的效率，可是在首次執行或者沒有緩存的狀況下仍是會有性能上的開銷，主要在如下方面
- Class.forName();會調用本地方法，咱們用到的method和field都會在此時加載進來，雖然會進行緩存，可是本地方法免不了有JAVA到C+=在到JAVA得轉換開銷
- class.getMethod()，會遍歷該class全部的公用方法，若是沒匹配到還會遍歷父類的全部方法，而且getMethods()方法會返回結果的一份拷貝，因此該操做不只消耗CPU還消耗堆內存，在熱點代碼中應該儘可能避免，或者進行緩存
- invoke參數是一個object數組，而object數組不支持java基礎類型，而自動裝箱也是很耗時的
反射的運用
- spring ioc
spring加載bean的流程基本都用到了反射機制
- 獲取類的實例 經過構造方法getInstance（靜態變量初始化，屬性賦值，構造方法）
- 若是實現了BeanNameAware接口，則用反射注入bean賦值給屬性
- 若是實現了BeanFactoryAware接口，則設置 beanFactory
- 若是實現了ApplicationContextAware，則設置ApplicationContext
- 調用BeanPostProcesser的預先初始化方法
- 若是實現了InitializingBean,調用AfterPropertySet方法
- 調用定製的 init-method()方法 對應的直接 @PostConstruct
- 調用BeanPostProcesser的後置初始化完畢的方法
- 序列化
fastjson能夠參考ObjectDeserializer的幾個實現 JavaBeanDeserializer和ASMJavaBeanDeserializer
動態代理
jdk提供了一個工具類來動態生成一個代理，容許在執行某一個方法時進行額外的處理
Proxy.newProxyInstance(ClassLoader loader,Class<?>[] interfaces,InvocationHandler h)
class HWInvocationHandler implements InvocationHandler{
//目標對象
private Object target;
public HWInvocationHandler(Object target){
this.target = target;
}
public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {
System.out.println("------插入前置通知代碼-------------");
//執行相應的目標方法
Object rs = method.invoke(target,args);
System.out.println("------插入後置處理代碼-------------");
return rs;
}
}
咱們分析下這個方法的實現，首先生成的代理對象，須要實現參數裏面聲明的全部接口，接口的實現應給委託給InvocationHandler進行處理，invocationHandler裏面能夠根據method聲明判斷是否須要作加強,因此所生成的代理類裏面必須可以獲取到InvocationHandler,在咱們沒法知道代理類的具體類型的時候，咱們能夠經過反射從構造方法裏將InvocationHandler傳給代理類的實例 因此 總的來講生成代理對象須要兩步
- 獲取代理類的class對象
- 經過class對象獲取構造方法，經過反射生成代理類的實例，並將InvocationHandler傳人
@CallerSensitive
public static Object newProxyInstance(ClassLoader loader,
Class<?>[] interfaces,
InvocationHandler h)
throws IllegalArgumentException
{
Objects.requireNonNull(h);
final Class<?>[] intfs = interfaces.clone();
/*
* Look up or generate the designated proxy class.
* 生成代理類
*/
Class<?> cl = getProxyClass0(loader, intfs);
/*
* Invoke its constructor with the designated invocation handler.
*/
try {
//獲取代理類的構造方法
final Constructor<?> cons = cl.getConstructor(constructorParams);
final InvocationHandler ih = h;
if (!Modifier.isPublic(cl.getModifiers())) {
AccessController.doPrivileged(new PrivilegedAction<Void>() {
public Void run() {
cons.setAccessible(true);
return null;
}
});
}
//獲取代理類的實例,而且將invocationhandler傳人
return cons.newInstance(new Object[]{h});
} catch (IllegalAccessException|InstantiationException e) {
...
}
}
下面咱們在看下 getProxyClass0 如何獲取代理類的class對象，這裏idk經過WeakCache來緩存已經生成的class對象，由於生成該class經過字節碼生成仍是很耗時，同時爲了解決以前因爲動態代理生成太多class對象致使內存不足，因此這裏經過弱引用WeakReference來緩存所生成的代理對象class，當發生GC的時候若是該class對象沒有其餘的強引用將會被直接回收 生成代理類的class在ProxyGenerator的generateProxyClass方法內實現，該方法返回一個byte[]數組，最後經過一個本地方法加載到虛擬機，因此能夠看出生成該對象仍是很是耗時的
//生成字節碼數組
byte[] proxyClassFile = ProxyGenerator.generateProxyClass(
proxyName, interfaces, accessFlags);
try {
//加載進虛擬機
return defineClass0(loader, proxyName,
proxyClassFile, 0, proxyClassFile.length);
} catch (ClassFormatError e) {
/*
* A ClassFormatError here means that (barring bugs in the
* proxy class generation code) there was some other
* invalid aspect of the arguments supplied to the proxy
* class creation (such as virtual machine limitations
* exceeded).
*/
throw new IllegalArgumentException(e.toString());
}
private byte[] generateClassFile() {
this.addProxyMethod(hashCodeMethod, Object.class);
this.addProxyMethod(equalsMethod, Object.class);
this.addProxyMethod(toStringMethod, Object.class);
Class[] var1 = this.interfaces;
int var2 = var1.length;
int var3;
Class var4;
for(var3 = 0; var3 < var2; ++var3) {
var4 = var1[var3];
Method[] var5 = var4.getMethods();
int var6 = var5.length;
for(int var7 = 0; var7 < var6; ++var7) {
Method var8 = var5[var7];
this.addProxyMethod(var8, var4);
}
}
this.methods.add(this.generateConstructor());
...
}
//生成一個帶invocationhandler參數的構造方法
private ProxyGenerator.MethodInfo generateConstructor() throws IOException {
ProxyGenerator.MethodInfo var1 = new ProxyGenerator.MethodInfo("<init>", "(Ljava/lang/reflect/InvocationHandler;)V", 1);
DataOutputStream var2 = new DataOutputStream(var1.code);
this.code_aload(0, var2);
this.code_aload(1, var2);
var2.writeByte(183);
var2.writeShort(this.cp.getMethodRef("java/lang/reflect/Proxy", "<init>", "(Ljava/lang/reflect/InvocationHandler;)V"));
var2.writeByte(177);
var1.maxStack = 10;
var1.maxLocals = 2;
var1.declaredExceptions = new short[0];
return var1;
}
上面的流程能夠簡單概括爲
- 增長hashcode,equals,toString方法
- 增長全部接口中聲明的未實現方法
- 增長一個方法參數爲java/lang/reflect/InvocationHandler的構造方法
- 其餘靜態初始化數據
動態代理的應用
-
spring-aop
spring aop默認基於jdk動態代理來實現，咱們來看下下面這個經典的面試問題
一個類裏面,兩個方法A和方法B,方法B上有加註解作事物加強,那麼A調用this.B爲何沒有事物效果？
由於spring-aop默認基於jdk的動態代理實現，最終執行是經過生成的代理對象的,而代理對象執行A方法和B方法實際上是調用的InvocationHandler裏面的加強後的方法,其中B方法是通過InvocationHandler作加強在方法先後增長了事物開啓和提交的代碼,而真正執行代碼是經過methodB.invoke(原始對象) 而A方法的實現內部雖然包含了this.B方法 但實際上是調用了methodA.invoke(原始對象),而這一句代碼至關於調用的是原始對象的methodA方法,而這裏面的this.B()方法實際上是調用的原始對象的B方法,沒有進行過事物加強,而若是是經過cglib作字節碼加強,生成這個類的子類,這種調用this.B方法是有事物效果的
-
rpc consumer
有過RMI開發經驗的人可能會很熟悉,爲何在對外export rmi服務的時候會分別在client和server生成兩個stub文件,其中client的文件其實就是用動態代理生成了一個代理類 這個代理類,實現了所要對外提供服務的全部接口,每一個方法的實現其實就是將接口信息,方法聲明,參數,返回值信息經過網絡發給服務端,而服務端收到請求後經過找到對應的實現而後用反射method.invoke進行調用,而後將結果返回給客戶端
其實其餘的RPC框架的實現方式大體和這個相似,只是客戶端的代理類,可能不只要將方法聲明經過網絡傳輸給服務提供方,也能夠作一下服務路由,負載均衡,以及傳輸一些額外的attachment數據給provider
公衆號：內核小王子
- 1. 反射和動態代理
- 2. 反射+動態代理
- 3. java反射+動態代理
- 4. 反射及動態代理
- 5. 【C#反射-動態建立對象】
- 6. c#反射動態建立窗體
- 7. java的動態代理和反射
- 8. java的反射和動態代理
- 9. 經過泛型反射和cglib動態代理方式建立代理對象
- 10. 反射實現動態代理原理
- 更多相關文章...
- • Spring JDK動態代理（附帶實例） - Spring教程
- • Spring CGLlB動態代理（附帶實例） - Spring教程
- • SpringBoot中properties文件不能自動提示解決方法
- • 適用於PHP初學者的學習線路和建議
-
每一个你不满意的现在，都有一个你没有努力的曾经。
- 1. 反射和動態代理
- 2. 反射+動態代理
- 3. java反射+動態代理
- 4. 反射及動態代理
- 5. 【C#反射-動態建立對象】
- 6. c#反射動態建立窗體
- 7. java的動態代理和反射
- 8. java的反射和動態代理
- 9. 經過泛型反射和cglib動態代理方式建立代理對象
- 10. 反射實現動態代理原理