# 反射到底是好是坏

说到 Java 中的反射,初学者在刚刚接触到反射的各种高级特性时,往往表示十分兴奋,甚至会在一些不需要使用反射的场景中强行使用反射来「炫技」。而经验较为丰富的长者,看到反射时往往会发出灵魂三问:为什么要用反射?反射不会降低性能么?不用还有什么办法可以解决这个问题?

那么今天我们就来深入探讨下,反射到底对性能有多大影响?顺便探讨下,反射为什么对性能有影响?

# 编码试验

在我们分析具体原理之前,我们可以通过编写代码做实验得出结论。

反射可能会涉及多种类型的操作,比如生成实例,获取 / 设置变量属性,调用方法等。经过简单的思考,我们认为生成实例对性能的影响相对其他操作要大一些,所以我们采用生成实例来做试验。

在如下代码中,我们定义了一个类 InnerClass ,我们测试分别使用 new反射 来生成 MAX_TIMES 个实例,并打印出耗时时间。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
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 {
}
}

输出日志:

1
2
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 个试试,输出日志:

1
2
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 次,这种场景下,我们还能理直气壮地说反射性能很低么?

很显然,不能。

除了代码执行耗时,我们再看看反射对内存的影响。我们仍然以生成 10 万 个实例为目标,对上述代码做略微改动,依次只保留 new 方式和反射方式,然后运行程序,观察内存占用情况。

img

使用 new 方式

img

使用反射

对比两图,我们可以看到第二张图中多了很多 ConstructorClass 对象实例,这两部分占用的内存 2.7M。因此,我们可以得出结论,反射会产生大量的临时对象,并且会占用额外内存空间。

# 刨根问底:反射原理是什么

我们以前面试验中反射生成实例的代码为入口。

首先回顾下虚拟机中类的生命周期:加载,连接(验证,准备,解析),初始化,使用,卸载。在加载的过程 中,虚拟机会把类的字节码转换成运行时数据结构,并保存在方法区,在内存中会生成一个代表这个类数据结构的 java.lang.Class 对象,后续访问这个类的数据结构就可以通过这个 Class 对象来访问。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
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 代码为源码。

1
2
3
4
5
6
7
@CallerSensitive
public Constructor<T> getDeclaredConstructor(Class<?>... parameterTypes)
throws NoSuchMethodException, SecurityException {
// 权限检查
checkMemberAccess(Member.DECLARED, Reflection.getCallerClass(), true);
return getConstructor0(parameterTypes, Member.DECLARED);
}

getDeclaredConstructor 方法首先做了权限检查,然后直接调用 getConstructor0 方法。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
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 。它对应的数据结构是:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
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() 方法获取的。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
// 定义在 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 方法。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
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 中看看获取构造方法的流程。

img

privateGetDeclaredConstructors 流程图

可以看到对于普通类,最终通过调用 getDeclaredConstructors0 方法获取的构造方法列表。

1
private native Constructor<T>[] getDeclaredConstructors0(boolean publicOnly);

这个方法是 native 的,具体逻辑在 jdk 源码中。

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
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> 即可。

1
2
3
4
bool isMethodConstructor(Method * self)
{
return !isMethodStatic(self) && strcmp(self->classMember.name, "<init>") == 0;
}

所以核心的逻辑变成了 Class 中的 methods 数组何时被初始化赋值的?我们刨根问底的追踪下。

我们先找到类加载到虚拟机中的入口方法 loadNonArrayClass

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
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 方法。

1
2
3
4
5
6
7
8
Class * parseClassFile(char * classContent, int32_t classSize)
{
ClassFile * classFile = NULL;

classFile = parseClassData(classContent, classSize);

return newClass(classFile);
}

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
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 中。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
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 数组。

总算梳理清楚了,反射创建对象的调用链为:

1
2
3
loadClass -> loadNonArrayClass -> parseClassFile -> newMethods -> Class 的 methods数组

privateGetDeclaredConstructors -> getDeclaredConstructors0 -> getClassConstructors (过滤Class 的 methods数组)

到目前为止,我们搞明白反射时如何找到对应的构造方法的。下面我们来看 newInstance 方法。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
(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 方法。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
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 方法。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
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 类。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
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 方法如下。

1
2
3
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 代码,可以看到第三个逻辑:

1
2
3
4
// 如果是 ConstructorAccessorImpl 的子类的话,返回 BootstrapConstructorAccessorImpl 
else if (Reflection.isSubclassOf(var2, ConstructorAccessorImpl.class)) {
return new BootstrapConstructorAccessorImpl(var1);
}

最终执行的是 BootstrapConstructorAccessorImplnewInstance 方法。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
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. 反射对内存占用还有一定影响的,在内存敏感的场景下,谨慎使用反射。
Edited on Views times