Java 反射真的很慢嗎?

反射究竟是好是壞

說到Java 中的反射,初學者在剛剛接觸到反射的各類高級特性時,每每表示十分興奮,甚至會在一些不須要使用反射的場景中強行使用反射來「炫技」。而經驗較爲豐富的長者,看到反射時每每會發出靈魂三問:爲何要用反射?反射不會下降性能麼?不用還有什麼辦法能夠解決這個問題?java

那麼今天咱們就來深刻探討下,反射到底對性能有多大影響?順便探討下,反射爲何對性能有影響?git

編碼試驗

在咱們分析具體原理以前,咱們能夠經過編寫代碼作實驗得出結論。github

反射可能會涉及多種類型的操做,好比生成實例,獲取/設置變量屬性,調用方法等。通過簡單的思考,咱們認爲生成實例對性能的影響相對其餘操做要大一些,因此咱們採用生成實例來作試驗。面試

在以下代碼中,咱們定義了一個類 InnerClass,咱們測試分別使用new反射來生成 MAX_TIMES個實例,並打印出耗時時間。數組

public class MainActivity extends AppCompatActivity {

    private static final String TAG = "MainAc";
    private final int MAX_TIMES = 100 * 1000;
    private InnerClass innerList[];

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);

        innerList = new InnerClass[MAX_TIMES];

        long startTime = SystemClock.elapsedRealtime();
        for (int i=0; i < MAX_TIMES; i++) {
            innerList[i] = new InnerClass();
        }
        Log.e(TAG, "totalTime: " + (SystemClock.elapsedRealtime() - startTime));

        long startTime2 = SystemClock.elapsedRealtime();
        for (int i=0; i < MAX_TIMES; i++) {
            innerList[i] = newInstanceByReflection();
        }
        Log.e(TAG, "totalTime2: " + (SystemClock.elapsedRealtime() - startTime2));
    }

    public InnerClass newInstanceByReflection() {
        Class clazz = InnerClass.class;
        try {
            return (InnerClass) clazz.getDeclaredConstructor().newInstance();
        } catch (NoSuchMethodException e) {
            e.printStackTrace();
        } catch (IllegalAccessException e) {
            e.printStackTrace();
        } catch (InstantiationException e) {
            e.printStackTrace();
        } catch (InvocationTargetException e) {
            e.printStackTrace();
        }
        return null;
    }

    static class InnerClass {
    }
}
複製代碼

輸出日誌:緩存

2020-03-19 22:34:49.738 2151-2151/? E/MainAc: totalTime: 15
2020-03-19 22:34:50.409 2151-2151/? E/MainAc: totalTime2: 670
複製代碼

使用反射生成 10萬 個實例,耗時 670ms,明顯高於直接使用 new關鍵字的 15ms,因此反射性能低。別急,這個結論總結的還有點早,咱們將要生成的實例總數改成 1000個試試,輸出日誌:安全

2020-03-19 22:39:21.287 3641-3641/com.example.myapplication E/MainAc: totalTime: 2
2020-03-19 22:39:21.296 3641-3641/com.example.myapplication E/MainAc: totalTime2: 9
複製代碼

使用反射生成 1000 個實例,雖然須要9ms,高於new的 2ms,可是 9ms 和 2ms 的差距自己肉眼不可見,並且一般咱們在業務中寫的反射通常來講執行頻率也未必會超過 1000 次,這種場景下,咱們還能義正詞嚴地說反射性能很低麼?bash

很顯然,不能。微信

除了代碼執行耗時,咱們再看看反射對內存的影響。咱們仍然以生成 10萬 個實例爲目標,對上述代碼作略微改動,依次只保留 new 方式和反射方式,而後運行程序,觀察內存佔用狀況。數據結構

使用 new 方式

使用反射

對比兩圖,咱們能夠看到第二張圖中多了不少 ConstructorClass對象實例,這兩部分佔用的內存2.7M。所以,咱們能夠得出結論,反射會產生大量的臨時對象,而且會佔用額外內存空間。

刨根問底:反射原理是什麼

咱們之前面試驗中反射生成實例的代碼爲入口。

首先回顧下虛擬機中類的生命週期:加載,鏈接(驗證,準備,解析),初始化,使用,卸載。在加載的過程 中,虛擬機會把類的字節碼轉換成運行時數據結構,並保存在方法區,在內存中會生成一個表明這個類數據結構的 java.lang.Class 對象,後續訪問這個類的數據結構就能夠經過這個 Class 對象來訪問。

public InnerClass newInstanceByReflection() {
    // 獲取虛擬機中 InnerClass 類的 Class 對象
    Class clazz = InnerClass.class;
    try {
        return (InnerClass) clazz.getDeclaredConstructor().newInstance();
    } catch (NoSuchMethodException e) {
        e.printStackTrace();
    } catch (IllegalAccessException e) {
        e.printStackTrace();
    } catch (InstantiationException e) {
        e.printStackTrace();
    } catch (InvocationTargetException e) {
        e.printStackTrace();
    }
    return null;
}
複製代碼

代碼中 clazz.getDeclaredConstructor() 用於獲取類中定義的構造方法,因爲咱們沒有顯式定義構造方法,因此會返回編譯器爲咱們本身生成的默認無參構造方法。

下面咱們看下 getDeclaredConstructor是如何返回構造方法的。如下均以 jdk 1.8代碼爲源碼。

@CallerSensitive
public Constructor<T> getDeclaredConstructor(Class<?>... parameterTypes) throws NoSuchMethodException, SecurityException {
    // 權限檢查
    checkMemberAccess(Member.DECLARED, Reflection.getCallerClass(), true);
    return getConstructor0(parameterTypes, Member.DECLARED);
}
複製代碼

getDeclaredConstructor 方法首先作了權限檢查,而後直接調用 getConstructor0 方法。

private Constructor<T> getConstructor0(Class<?>[] parameterTypes, int which) throws NoSuchMethodException {
    // privateGetDeclaredConstructors 方法是獲取全部的構造方法數組
    Constructor<T>[] constructors = privateGetDeclaredConstructors((which == Member.PUBLIC));
    // 遍歷全部的構造方法數組,根據傳入的參數類型依次匹配,找到合適的構造方法後就會拷貝一份做爲返回值
    for (Constructor<T> constructor : constructors) {
        if (arrayContentsEq(parameterTypes,
                            constructor.getParameterTypes())) {
            // 拷貝構造方法
            return getReflectionFactory().copyConstructor(constructor);
        }
    }
    // 沒有找到的話,就拋出異常 
    throw new NoSuchMethodException(getName() + ".<init>" + argumentTypesToString(parameterTypes));
}
複製代碼

getConstructor0 方法主要作了兩件事:

  • 獲取全部構造方法組成的數組
  • 遍歷構造方法數組,找到匹配的

遍歷匹配沒啥好說的,咱們重點看下第一件事,怎麼獲取的全部構造方法數組,也就是這個方法 privateGetDeclaredConstructors

private Constructor<T>[] privateGetDeclaredConstructors(boolean publicOnly) {
    checkInitted();
    Constructor<T>[] res;
    // 獲取緩存的 ReflectionData 數據
    ReflectionData<T> rd = reflectionData();
    // 若是緩存中有 ReflectionData,就先看看 ReflectionData 中的 publicConstructors 或 declaredConstructors是否爲空
    if (rd != null) {
        res = publicOnly ? rd.publicConstructors : rd.declaredConstructors;
        if (res != null) return res;
    }
    // 若是沒有緩存,或者緩存中構造方法數組爲空
    // No cached value available; request value from VM
    // 對接口類型的字節碼特殊處理
    if (isInterface()) {
        @SuppressWarnings("unchecked")
        // 若是是接口類型,那麼生成一個長度爲0的構造方法數組
        Constructor<T>[] temporaryRes = (Constructor<T>[]) new Constructor<?>[0];
        res = temporaryRes;
    } else {
        // 若是不是接口類型,就調用 getDeclaredConstructors0 獲取構造方法數組
        res = getDeclaredConstructors0(publicOnly);
    }
    // 獲取到構造方法數組後,再賦值給緩存 ReflectionData 中的對應屬性
    if (rd != null) {
        if (publicOnly) {
            rd.publicConstructors = res;
        } else {
            rd.declaredConstructors = res;
        }
    }
    return res;
}
複製代碼

上述代碼中我已經對關鍵代碼進行了註釋,在講解整個流程以前,咱們看到了一個陌生的類型 ReflectionData。它對應的數據結構是:

private static class ReflectionData<T> {
    volatile Field[] declaredFields;
    volatile Field[] publicFields;
    volatile Method[] declaredMethods;
    volatile Method[] publicMethods;
    volatile Constructor<T>[] declaredConstructors;
    volatile Constructor<T>[] publicConstructors;
    // Intermediate results for getFields and getMethods
    volatile Field[] declaredPublicFields;
    volatile Method[] declaredPublicMethods;
    volatile Class<?>[] interfaces;

    // Value of classRedefinedCount when we created this ReflectionData instance
    final int redefinedCount;

    ReflectionData(int redefinedCount) {
        this.redefinedCount = redefinedCount;
    }
}
複製代碼

ReflectionData 這個類就是用來保存從虛擬機中獲取到的一些數據。同時咱們能夠看到全部反射屬性都使用了 volatile關鍵字修飾。

獲取緩存的 ReflectionData 數據是經過調用reflectionData()方法獲取的。

// 定義在 Class 類中的反射緩存對象
private volatile transient SoftReference<ReflectionData<T>> reflectionData;

private ReflectionData<T> reflectionData() {
    SoftReference<ReflectionData<T>> reflectionData = this.reflectionData;
    int classRedefinedCount = this.classRedefinedCount;
    ReflectionData<T> rd;
    if (useCaches &&
        reflectionData != null &&
        (rd = reflectionData.get()) != null &&
        rd.redefinedCount == classRedefinedCount) {
        return rd;
    }
    // else no SoftReference or cleared SoftReference or stale ReflectionData
    // -> create and replace new instance
    return newReflectionData(reflectionData, classRedefinedCount);
}
複製代碼

咱們能夠看到 reflectionData其實是一個軟引用,軟引用會在內存不足的狀況下被虛擬機回收,因此reflectionData()方法在開始的地方,先判斷了是否可使用緩存以及緩存是否失效,若是失效了,就會調用 newReflectionData方法生成一個新的 ReflectionData 實例。

接下來看看 newReflectionData 方法。

private ReflectionData<T> newReflectionData(SoftReference<ReflectionData<T>> oldReflectionData, int classRedefinedCount) {
    // 若是不容許使用緩存,直接返回 null
    if (!useCaches) return null;
	
    while (true) {
        ReflectionData<T> rd = new ReflectionData<>(classRedefinedCount);
        // try to CAS it...
        if (Atomic.casReflectionData(this, oldReflectionData, new SoftReference<>(rd))) {
            return rd;
        }
        // else retry
        oldReflectionData = this.reflectionData;
        classRedefinedCount = this.classRedefinedCount;
        if (oldReflectionData != null &&
            (rd = oldReflectionData.get()) != null &&
            rd.redefinedCount == classRedefinedCount) {
            return rd;
        }
    }
}
複製代碼

newReflectionData中使用 volatile + 死循環 + CAS 機制 保證線程安全。注意到這裏的死循環每執行一次都會構造一個新的 ReflectionData 實例。

你可能會有疑問,ClassreflectionData屬性何時被賦值的,實際上是封裝在Atomic.casReflectionData這個方法裏了,他會檢測當前Class對象中的reflectionData是否與oldReflectionData相等,若是相等,就會把new SoftReference<>(rd)賦值給 reflectionData

到如今爲止,關於 ReflectionData的背景知識都介紹完了。咱們再回到 privateGetDeclaredConstructors中看看獲取構造方法的流程。

privateGetDeclaredConstructors流程圖

能夠看到對於普通類,最終經過調用 getDeclaredConstructors0方法獲取的構造方法列表。

private native Constructor<T>[] getDeclaredConstructors0(boolean publicOnly);
複製代碼

這個方法是 native 的,具體邏輯在 jdk 源碼中。

native/java/lang/Class_getDeclaredConstructors0.c 文件中,

void getDeclaredConstructors0(Frame * frame) {
    // Frame 能夠理解爲調用native方法時,java層傳遞過來的數據的一種封裝
	LocalVars * vars = frame->localVars;
	Object * classObj = getLocalVarsThis(vars);
    // 取得java方法的入參
	bool publicOnly = getLocalVarsBoolean(vars, 1);

	uint16_t constructorsCount = 0;
    // 獲取要查詢的類的 Class 對象
	Class * c = classObj->extra;
    // 獲取這個類的全部構造方法,且數量保存在 constructorsCount 中
	Method* * constructors = getClassConstructors(c, publicOnly, &constructorsCount);
	// 獲取 java 方法調用所屬的 classLoader
	ClassLoader *  classLoader = frame->method->classMember.attachClass->classLoader;
	// 拿到 Constructor 對應的 class 對象
	Class * constructorClass = loadClass(classLoader, "java/lang/reflect/Constructor");
    //建立一個長度爲 constructorsCount 的數組保存構造方法
	Object * constructorArr = newArray(arrayClass(constructorClass), constructorsCount);

	pushOperandRef(frame->operandStack, constructorArr);
	// 後面是具體的賦值邏輯。將native中的Method對象轉化爲java層的Constructor對象
	if (constructorsCount > 0)
	{
		Thread * thread = frame->thread;
		Object* * constructorObjs = getObjectRefs(constructorArr);

		Method * constructorInitMethod = getClassConstructor(constructorClass, _constructorConstructorDescriptor);
		for (uint16_t i = 0; i < constructorsCount; i++)
		{
			Method * constructor = constructors[i];

			Object * constructorObj = newObject(constructorClass);
			constructorObj->extra = constructor;
			constructorObjs[i] = constructorObj;

			OperandStack * ops = newOperandStack(9);
			pushOperandRef(ops, constructorObj);
			pushOperandRef(ops, classObj);
			pushOperandRef(ops, toClassArr(classLoader, methodParameterTypes(constructor), constructor->parsedDescriptor->parameterTypesCount));
			if (constructor->exceptions != NULL)
				pushOperandRef(ops, toClassArr(classLoader, methodExceptionTypes(constructor), constructor->exceptions->number_of_exceptions));
			else
				pushOperandRef(ops, toClassArr(classLoader, methodExceptionTypes(constructor), 0));
			pushOperandInt(ops, constructor->classMember.accessFlags);
			pushOperandInt(ops, 0);
			pushOperandRef(ops, getSignatureStr(classLoader, constructor->classMember.signature));         // signature
			pushOperandRef(ops, toByteArr(classLoader, constructor->classMember.annotationData, constructor->classMember.annotationDataLen));
			pushOperandRef(ops, toByteArr(classLoader, constructor->parameterAnnotationData, constructor->parameterAnnotationDataLen));


			Frame * shimFrame = newShimFrame(thread, ops);
			pushThreadFrame(thread, shimFrame);

			// init constructorObj
			InvokeMethod(shimFrame, constructorInitMethod);
		}


	}
}
複製代碼

從上面的邏輯,能夠知道獲取構造方法的核心方法是 getClassConstructors ,所在文件爲 rtda/heap/class.c

Method* * getClassConstructors(Class * self, bool publicOnly, uint16_t * constructorsCount) {
    // 分配大小爲 sizeof(Method) 的長度爲 methodsCount 的連續內存地址,即數組
	Method* * constructors = calloc(self->methodsCount, sizeof(Method));
	*constructorsCount = 0;
    // 在native 層,構造方法和普通方法都存在 methods 中,逐一遍歷
	for (uint16_t i = 0; i < self->methodsCount; i++)
	{
		Method * method = self->methods + i;
        // 判斷是不是構造方法
		if (isMethodConstructor(method))
		{
            // 檢查權限
			if (!publicOnly || isMethodPublic(method))
			{
                // 符合條件的構造方法依次存到數組中
				constructors[*constructorsCount] = method;
				(*constructorsCount)++;
			}
		}
	}
	return constructors;
}
複製代碼

能夠看到getClassConstructors實際上就是對 methods 進行了一次過濾,過濾的條件爲:1.是構造方法;2.權限一致。

isMethodConstructor 方法的判斷邏輯也是十分簡單,不是靜態方法,並且方法名是<init>便可。

bool isMethodConstructor(Method * self) {
	return !isMethodStatic(self) && strcmp(self->classMember.name, "<init>") == 0;	
}
複製代碼

因此核心的邏輯變成了Class中的 methods數組什麼時候被初始化賦值的?咱們刨根問底的追蹤下。

咱們先找到類加載到虛擬機中的入口方法 loadNonArrayClass

Class * loadNonArrayClass(ClassLoader * classLoader, const char * className) {
	int32_t classSize = 0;
	char * classContent = NULL;
	Class * loadClass = NULL;
	classSize = readClass(className, &classContent);
	if (classSize > 0 && classContent != NULL){
#if 0
		printf("class size:%d,class data:[", classSize);
		for (int32_t i = 0; i < classSize; i++)
		{
			printf("0x%02x ", classContent[i]);
		}
		printf("]\n");
#endif
	}
	if (classSize <= 0)
	{
		printf("Could not found target class\n");
		exit(127);
	}
	// 解析字節碼文件
	loadClass = parseClassFile(classContent, classSize);
	loadClass->classLoader = classLoader;
	// 加載
	defineClass(classLoader, loadClass);
	// 連接
	linkClass(classLoader, loadClass);

	//printf("[Loaded %s\n", loadClass->name);
	return loadClass;
}

複製代碼

parseClassFile方法中,調用了newClass方法。

Class * parseClassFile(char * classContent, int32_t classSize) {
	ClassFile * classFile = NULL;

	classFile = parseClassData(classContent, classSize);

	return newClass(classFile);
}
複製代碼

newClass方法在rtda/heap/class.c文件中。

Class * newClass(ClassFile * classFile) {
	Class * c = calloc(1, sizeof(Class));
	c->accessFlags = classFile->accessFlags;
	c->sourceFile = getClassSourceFileName(classFile);
	newClassName(c, classFile);
	newSuperClassName(c, classFile);
	newInterfacesName(c, classFile);
	newConstantPool(c, classFile);
	newFields(c, classFile);
	newMethods(c, classFile);
	return c;

}
複製代碼

能夠看到,在native層建立了一個Class對象,咱們重點看newMethods(c, classFile)方法啊,這個方法定義在rtda/heap/method.c中。

Method * newMethods(struct Class * c, ClassFile * classFile) {
	c->methodsCount = classFile->methodsCount;
	c->methods = NULL;
	if (c->methodsCount == 0)
		return NULL;

	c->methods = calloc(classFile->methodsCount, sizeof(Method));
	for (uint16_t i = 0; i < c->methodsCount; i++)
	{		
		c->methods[i].classMember.attachClass = c;
		copyMethodInfo(&c->methods[i], &classFile->methods[i], classFile);
		copyAttributes(&c->methods[i], &classFile->methods[i], classFile);
		MethodDescriptor * md = parseMethodDescriptor(c->methods[i].classMember.descriptor);
		c->methods[i].parsedDescriptor = md;
		calcArgSlotCount(&c->methods[i]);
		if (isMethodNative(&c->methods[i]))
		{
			injectCodeAttribute(&c->methods[i], md->returnType);
		}
	}
 
	return NULL;
}
複製代碼

上述代碼能夠看出,實際上就是把ClassFile中解析到的方法逐一賦值給了 Class 對象的 methods 數組。

總算梳理清楚了,反射建立對象的調用鏈爲:

loadClass -> loadNonArrayClass -> parseClassFile -> newMethods -> Class 的 methods數組

privateGetDeclaredConstructors -> getDeclaredConstructors0 -> getClassConstructors (過濾Class 的 methods數組)
複製代碼

到目前爲止,咱們搞明白反射時如何找到對應的構造方法的。下面咱們來看 newInstance 方法。

(InnerClass) clazz.getDeclaredConstructor().newInstance();
複製代碼
public T newInstance(Object ... initargs) throws InstantiationException, IllegalAccessException, IllegalArgumentException, InvocationTargetException {
        // 構造方法是否被重載了
        if (!override) {
            if (!Reflection.quickCheckMemberAccess(clazz, modifiers)) {
                Class<?> caller = Reflection.getCallerClass();
                // 檢查權限
                checkAccess(caller, clazz, null, modifiers);
            }
        }
        // 枚舉類型報錯
        if ((clazz.getModifiers() & Modifier.ENUM) != 0)
            throw new IllegalArgumentException("Cannot reflectively create enum objects");
        // ConstructorAccessor 是緩存的,若是爲空,就去建立一個
        ConstructorAccessor ca = constructorAccessor;   // read volatile
        if (ca == null) {
            // 建立 ConstructorAccessor
            ca = acquireConstructorAccessor();
        }
        @SuppressWarnings("unchecked")
        // 使用 ConstructorAccessor 的 newInstance 構造實例
        T inst = (T) ca.newInstance(initargs);
        return inst;
    }
複製代碼

接着看下 acquireConstructorAccessor 方法。

private ConstructorAccessor acquireConstructorAccessor() {
    // First check to see if one has been created yet, and take it
    // if so.
    ConstructorAccessor tmp = null;
    // 能夠理解爲緩存的對象
    if (root != null) tmp = root.getConstructorAccessor();
    if (tmp != null) {
        constructorAccessor = tmp;
    } else {
        // Otherwise fabricate one and propagate it up to the root
        // 生成一個 ConstructorAccessor,並緩存起來
        tmp = reflectionFactory.newConstructorAccessor(this);
        setConstructorAccessor(tmp);
    }

    return tmp;
}
複製代碼

繼續走到newConstructorAccessor方法。

public ConstructorAccessor newConstructorAccessor(Constructor<?> var1) {
        checkInitted();
        Class var2 = var1.getDeclaringClass();
    // 若是是抽象類,報錯
    if (Modifier.isAbstract(var2.getModifiers())) {
        return new InstantiationExceptionConstructorAccessorImpl((String)null);
    } 
    // 若是 Class 類報錯
    else if (var2 == Class.class) {
        return new InstantiationExceptionConstructorAccessorImpl("Can not instantiate java.lang.Class");
    } 
    // 若是是 ConstructorAccessorImpl 的子類的話,返回 BootstrapConstructorAccessorImpl 
    else if (Reflection.isSubclassOf(var2, ConstructorAccessorImpl.class)) {
        return new BootstrapConstructorAccessorImpl(var1);
    } 
    // 判斷 noInflation , 後面是判斷不是匿名類
    else if (noInflation && !ReflectUtil.isVMAnonymousClass(var1.getDeclaringClass())) {
        return (new MethodAccessorGenerator()).generateConstructor(var1.getDeclaringClass(), var1.getParameterTypes(), var1.getExceptionTypes(), var1.getModifiers());
    } 
    // 使用 NativeConstructorAccessorImpl 來生成實例
    else {
        NativeConstructorAccessorImpl var3 = new NativeConstructorAccessorImpl(var1);
        DelegatingConstructorAccessorImpl var4 = new DelegatingConstructorAccessorImpl(var3);
        var3.setParent(var4);
        return var4;
    }
}
複製代碼

具體邏輯,在上述代碼中已經註釋了。這裏提一下 noInflation

ReflectionFactory在執行全部方法前會檢查下是否執行過了checkInitted方法,這個方法會把noInflation的值和inflationThreshold從虛擬機的環境變量中讀取出來並賦值。

noInflationfalse並且不是匿名類時,就會使用MethodAccessorGenerator方式。不然就是用 NativeConstructorAccessorImpl的方式來生成。

默認noInflationfalse,因此咱們先看native調用的方式。關注 NativeConstructorAccessorImpl類。

class NativeConstructorAccessorImpl extends ConstructorAccessorImpl {
    private final Constructor<?> c;
    private DelegatingConstructorAccessorImpl parent;
    private int numInvocations;

    NativeConstructorAccessorImpl(Constructor<?> var1) {
        this.c = var1;
    }

    public Object newInstance(Object[] var1) throws InstantiationException, IllegalArgumentException, InvocationTargetException {
        if (++this.numInvocations > ReflectionFactory.inflationThreshold() && !ReflectUtil.isVMAnonymousClass(this.c.getDeclaringClass())) {
            ConstructorAccessorImpl var2 = (ConstructorAccessorImpl)(new MethodAccessorGenerator()).generateConstructor(this.c.getDeclaringClass(), this.c.getParameterTypes(), this.c.getExceptionTypes(), this.c.getModifiers());
            this.parent.setDelegate(var2);
        }

        return newInstance0(this.c, var1);
    }

    void setParent(DelegatingConstructorAccessorImpl var1) {
        this.parent = var1;
    }

    private static native Object newInstance0(Constructor<?> var0, Object[] var1) throws InstantiationException, IllegalArgumentException, InvocationTargetException;
}

複製代碼

咱們能夠看到 NativeConstructorAccessorImpl 中維護了一個計數器numInvocations,在每次調用newInstance方法生成實例時,就會對計數器自增,當計數器超過ReflectionFactory.inflationThreshold()的閾值,默認爲15,就會使用 ConstructorAccessorImpl替換 NativeConstructorAccessorImpl,後面就會直接調用MethodAccessorGenerator中的方法了。

咱們先看看沒到達閾值前,會調用native方法 newInstance0,這個方法定義在native/sun/reflect/NativeConstructorAccessorImpl.c中,具體newInstance0的流程我就不分析了,大體邏輯是操做堆棧執行方法。

而後咱們再看看超過閾值後,執行的是 MethodAccessorGenerator生成構造器的方式。這種方式與newConstructorAccessor方法中noInflationfalse的處理方式同樣。因此能夠解釋爲:java虛擬機在執行反射操做時,若是同一操做執行次數超過閾值,會從native生成實例的方式轉變爲java生成實例的方式。

MethodAccessorGeneratorMethodAccessorGenerator方法以下。

public ConstructorAccessor generateConstructor(Class<?> var1, Class<?>[] var2, Class<?>[] var3, int var4) {
    return (ConstructorAccessor)this.generate(var1, "<init>", var2, Void.TYPE, var3, var4, true, false, (Class)null);
}
複製代碼

繼續跟蹤下去能夠發現,反射調用構造方法其實是動態編寫字節碼,而且在虛擬機中把編好的字節碼加載成一個Class,這個Class其實是 ConstructorAccessorImpl 類型的,而後調用這個動態類的newInstance方法。回看剛剛咱們梳理的newConstructorAccessor代碼,能夠看到第三個邏輯:

// 若是是 ConstructorAccessorImpl 的子類的話,返回 BootstrapConstructorAccessorImpl 
else if (Reflection.isSubclassOf(var2, ConstructorAccessorImpl.class)) {
    return new BootstrapConstructorAccessorImpl(var1);
} 
複製代碼

最終執行的是 BootstrapConstructorAccessorImplnewInstance方法。

class BootstrapConstructorAccessorImpl extends ConstructorAccessorImpl {
    private final Constructor<?> constructor;

    BootstrapConstructorAccessorImpl(Constructor<?> var1) {
        this.constructor = var1;
    }

    public Object newInstance(Object[] var1) throws IllegalArgumentException, InvocationTargetException {
        try {
            return UnsafeFieldAccessorImpl.unsafe.allocateInstance(this.constructor.getDeclaringClass());
        } catch (InstantiationException var3) {
            throw new InvocationTargetException(var3);
        }
    }
}
複製代碼

最後是經過使用Unsafe類分配了一個實例。

反射帶來的問題

到如今爲止,咱們已經把反射生成實例的全部流程都搞清楚了。回到文章開頭的問題,咱們如今反思下,反射性能低麼?爲何?

  1. 反射調用過程當中會產生大量的臨時對象,這些對象會佔用內存,可能會致使頻繁 gc,從而影響性能。
  2. 反射調用方法時會從方法數組中遍歷查找,而且會檢查可見性等操做會耗時。
  3. 反射在達到必定次數時,會動態編寫字節碼並加載到內存中,這個字節碼沒有通過編譯器優化,也不能享受JIT優化。
  4. 反射通常會涉及自動裝箱/拆箱和類型轉換,都會帶來必定的資源開銷。

在Android中,咱們能夠在某些狀況下對反射進行優化。舉個例子,EventBus 2.x 會在 register 方法運行時,遍歷全部方法找到回調方法;而EventBus 3.x 則在編譯期間,將全部回調方法的信息保存的本身定義的 SubscriberMethodInfo 中,這樣能夠減小對運行時的性能影響。

本文的結論以下:

  1. 不要在性能敏感的應用中,頻繁調用反射。
  2. 若是反射執行的次數小於1000這個數量級,反射的耗時實際上與正常調用無太大差別。
  3. 反射對內存佔用還有必定影響的,在內存敏感的場景下,謹慎使用反射。

關於我

華中科技大學機械電子工程系碩士畢業,Android 高級工程師,佛系興趣型博客撰寫者。若是你想和我交流,能夠經過如下方式。

我的網站: orzangleli.com/

掘金:juejin.im/user/5796d5…

GitHub: github.com/hust2010107…

微信公衆號: Android開發實驗室

https://user-gold-cdn.xitu.io/2018/12/3/16774bbd97cdf7a8?w=258&h=258&f=jpeg&s=27337
相關文章
相關標籤/搜索