在我剛開始瞭解反射這個Java特性的時候,幾乎看到的每一篇文章都會有“Java反射不能頻繁使用”、“反射影響性能”之類的話語,當時只是當一個結論記下了這些話,卻沒有深究過為什麼,所以正好藉此機會來探究一下Java反射的代碼。 ...
1 背景
前段時間組內針對“拷貝實例屬性是應該用BeanUtils.copyProperties()還是MapStruct”這個問題進行了一次激烈的battle。支持MapStruct的同學給出了他嫌棄BeanUtils的理由:因為用了反射,所以慢。
這個理由一下子拉回了我遙遠的記憶,在我剛開始瞭解反射這個Java特性的時候,幾乎看到的每一篇文章都會有“Java反射不能頻繁使用”、“反射影響性能”之類的話語,當時只是當一個結論記下了這些話,卻沒有深究過為什麼,所以正好藉此機會來探究一下Java反射的代碼。
2 反射包結構梳理
反射相關的代碼主要在jdk rt.jar下的java.lang.reflect包下,還有一些相關類在其他包路徑下,這裡先按下不表。按照繼承和實現的關係先簡單劃分下java.lang.reflect包:
① Constructor、Method、Field三個類型分別可以描述實例的構造方法、普通方法和欄位。三種類型都直接或間接繼承了AccessibleObject這個類型,此類型里主要定義兩種方法,一種是通用的、對訪問許可權進行處理的方法,第二種是可供繼承重寫的、與註解相關的方法。
② 只看選中的五種類型,我們平常所用到的普通類型,譬如Integer、String,又或者是我們自定義的類型,都可以用Class類型的實例來表示。Java引入泛型之後,在JDK1.5中擴充了其他四種類型,用於泛型的表示。分別是ParameterizedType(參數化類型)、WildcardType(通配符類型)、TypeVariable(類型變數)、GenericArrayType(泛型數組)。
③ 與②中描述的五種基本類型對應,下圖這五個介面/類分別用來表示五種基本類型的註解相關數據。
④ 下圖為實現動態代理的相關類與介面。java.lang.reflect.Proxy主要是利用反射的一些方法獲取代理類的類對象,獲取其構造方法,由此構造出一個實例。
java.lang.reflect.InvocationHandler是代理類需要實現的介面,由代理類實現介面內的invoke方法,此方法會負責代理流程和被代理流程的執行順序組織。
3 目標類實例的構造源碼
以String類的對象實例化為例,看一下反射是如何進行對象實例化的。
Class<?> clz = Class.forName("java.lang.String");
String s =(String)clz.newInstance();
Class對象的構造由native方法完成,以java.lang.String類為例,先看看構造好的Class對象都有哪些屬性:
可以看到目前只有name一個屬性有值,其餘屬性暫時都是null或者預設值的狀態。
下圖是 clz.newInstance() 方法邏輯的流程圖,接下來對其中主要的兩個方法進行說明:
從上圖可以看出整個流程有兩個核心部分。因為通常情況下,對象的構造都需要依靠類里的構造方法來實現,所以第一部分就是拿到目標類對應的Constructor對象;第二部分就是利用Constructor對象,構造目標類的實例。
3.1 獲取Constructor對象
首先上一張Constructor對象的屬性圖:
java.lang.Class#getConstructor0
此方法中主要做的工作是首先拿到目標類的Constructor實例數組(主要由native方法實現),數組裡每一個對象都代表了目標類的一個構造方法。然後對數組進行遍歷,根據方法入參提供的parameterTypes,找到符合的Constructor對象,然後重新創造一個Constructor對象,屬性值與原Constructor一致(稱為副本Constructor),並且副本Constructor的屬性 root 指向源Constructor,相當於對源Constructor對象進行了一層封裝。
由於在getConstructor0()方法將返回值返回給調用方之後,調用方在後續的流程里進行了constructor.setAccesssible(true)的操作,這個方法的作用是關閉對constructor這個對象訪問時的Java語言訪問檢查。語言訪問檢查是個耗時的操作,所以合理猜測是為了提高反射性能關閉了這個檢查,又出於安全考慮,所以將最原始的對象進行了封裝。
private Constructor<T> getConstructor0(Class<?>[] parameterTypes,
int which) throws NoSuchMethodException
{
//1、拿到Constructor實例數組併進行篩選
Constructor<T>[] constructors = privateGetDeclaredConstructors((which == Member.PUBLIC));
//2、通過對入參的比較篩選出符合條件的Constructor
for (Constructor<T> constructor : constructors) {
if (arrayContentsEq(parameterTypes,
constructor.getParameterTypes())) {
//3、創建副本Constructor
return getReflectionFactory().copyConstructor(constructor);
}
}
throw new NoSuchMethodException(getName() + ".<init>" + argumentTypesToString(parameterTypes));
}
3.2 目標類實例的構造
sun.reflect.ConstructorAccessor#newInstance
此方法主要是利用上一步創建出來的Constructor對象,進行目標類實例的構造。Java為了提高反射的性能,為類實例的構造提供了兩種方案,一種是虛擬機自己實現的native方法,一種是JDK包里的Java方法。
首先來看代碼里對ConstructorAccessor對象的構造,通過代碼可以看出在方法newConstructorAccessor中構造了ConstructorAccessor介面的兩個實現類,兩個對象進行了相互引用,像這樣子:
//構造ConstructorAccessor對象
public ConstructorAccessor newConstructorAccessor(Constructor<?> var1) {
if (Modifier.isAbstract(var2.getModifiers())) {
......
} else {
NativeConstructorAccessorImpl var3 = new NativeConstructorAccessorImpl(var1);
DelegatingConstructorAccessorImpl var4 = new DelegatingConstructorAccessorImpl(var3);
var3.setParent(var4);
return var4;
}
}
在調用DelegatingConstructorAccessorImpl的newInstance方法時,相當於為NativeConstructorAccessorImpl做了一層代理,實際調用的是NativeConstructorAccessorImpl類實現的方法。
public Object newInstance(Object[] var1) throws InstantiationException, IllegalArgumentException, InvocationTargetException {
return this.delegate.newInstance(var1);
}
newInstance方法中決定使用哪種方法的是一個名為numInvocations的int類型的變數,每次調用到newInstance方法時,這個變數都會+1,當變數值超過閾值(15)時,就會使用Java方式進行目標類實例的創造,反之就會使用虛擬機實現的方式進行目標類實例的創造。
這樣做是因為Java版本的實現流程很長,其中還包含了位元組碼構造的流程,所以初次構造比較耗時,但是長久來說性能更好,而native版本是初期使用速度較塊,調用頻繁的話性能會有所下降,所以做了根據閾值來判斷使用哪個版本的設計。
public Object newInstance(Object[] var1) throws InstantiationException, IllegalArgumentException, InvocationTargetException {
if (++this.numInvocations > ReflectionFactory.inflationThreshold() && !ReflectUtil.isVMAnonymousClass(this.c.getDeclaringClass())) {
//Java方法構造對象
ConstructorAccessorImpl var2 = (ConstructorAccessorImpl)(new MethodAccessorGenerator()).generateConstructor(this.c.getDeclaringClass(), this.c.getParameterTypes(), this.c.getExceptionTypes(), this.c.getModifiers());
this.parent.setDelegate(var2);
}
//native方法實現實例化
return newInstance0(this.c, var1);
}
重點關註以下Java版本的實現流程,首先構造了一個ConstructorAccessorImpl類的對象。這個對象的構造主要是依靠在代碼里按照位元組碼文件的格式構造出來一個位元組數組實現的。首先創建了一個ByteVactor介面的實現類對象,此類有兩個屬性,一個位元組數組,一個int類型的數用來標識位置。ClassFileAssembler類主要負責把各類值轉化成位元組碼的格式然後填充到ByteVactor的實現類對象里。最後由ClassDefiner.defineClass方法對位元組碼數組進行處理,構造出ConstructorAccessorImpl對象。 最後ConstructorAccessorImpl實例還是會被傳給newInstance0()這個native方法,以此來構造最終的目標類實例
private MagicAccessorImpl generate(final Class<?> var1, String var2, Class<?>[] var3, Class<?> var4, Class<?>[] var5, int var6, boolean var7, boolean var8, Class<?> var9) {
//創建ByteVectorImpl對象
ByteVector var10 = ByteVectorFactory.create();
//創建ClassFileAssembler對象
this.asm = new ClassFileAssembler(var10);
......
var10.trim();
//拿出構造好的位元組數組(就是位元組碼文件的格式)
final byte[] var17 = var10.getData();
return (MagicAccessorImpl)AccessController.doPrivileged(new PrivilegedAction<MagicAccessorImpl>() {
public MagicAccessorImpl run() {
try {
//調用native方法,創建ConstructorAccessorImpl類的實例
//最後ConstructorAccessorImpl實例還是會被傳給newInstance0()這個native方法,以此來構造最終的目標類實例
return (MagicAccessorImpl)ClassDefiner.defineClass(var13, var17, 0, var17.length, var1.getClassLoader()).newInstance();
} catch (IllegalAccessException | InstantiationException var2) {
throw new InternalError(var2);
}
}
});
}
}
4 小結
最後根據上述學習思考下Java反射到底慢不慢這個問題。首先可以看到JDK為“反射時創建對象的過程”提供了兩套實現,native版本更快但是也使得JVM無法對其進行一些優化(譬如JIT的方法內聯),當方法成為熱點時,轉用Java版本來進行實現則優化了這個問題。但Java版本的實現過程中需要動態生成位元組碼,還要載入一些額外的類,造成了記憶體的消耗,所以使用反射的時候還是應當註意一些是否會因為使用過多而造成記憶體溢出。
一次不成熟的源碼學習歷程,如有錯誤還請指正。
參考資料:
https://rednaxelafx.iteye.com/blog/548536
作者:京東物流 秦曌怡
來源:京東雲開發者社區