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

作者：京東物流秦曌怡

來源：京東云開發者社區

轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/556305.html

標籤：其他

上一篇：帶有 Spring Boot 后端的 Vue.js 前端

下一篇：返回列表