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
作者：京東物流 秦曌怡
來源：京東雲開發者社群