反射（Reflection）底层原理与源码深度剖析

Java 是一门静态类型语言，但反射（Reflection）机制赋予了它在运行时如同动态语言般的灵活性。各大框架（Spring、MyBatis、Hibernate）几乎全部建立在反射的基石之上。

但反射究竟是什么？当我们调用 Class.forName() 或 method.invoke() 时，JVM 底层到底发生了什么？这篇文章将带你剥开 API 的外壳，深入堆内存、元空间（Metaspace）以及 OpenJDK 的底层源码，彻底看清反射的本质。

1. 什么是反射？

一句话概括：反射是 Java 程序在运行期间，动态感知和操作类元数据（Metadata）的能力。

这就像是给 JVM 戴上了一副「X 光透视镜」。在普通情况下（不使用反射），你只能使用在编译期间就已经被按死在代码里的类和方法。而有了 X 光镜，只要你扔给 JVM 一个对象，它能在运行时透视出这个对象是什么类型、有哪些私有变量、并强行调用它的私有方法。

为什么需要反射？

如果没有反射，我们只能这样写代码（硬编码）：

// 编译期就必须确定类型
Person p = new Person();
p.sayHello();

如果我们要写一个通用的 JSON 解析框架或者像 Spring 这样的 IoC 容器，框架在被编译的时候，根本不知道未来它要处理的业务类叫 Person 还是 Order。它必须在运行时读取外部配置（或者注解），动态地把一个字符串 "com.example.Person" 实例化为对象。 这便是反射解决的终极问题——解耦和动态化。

2. 两个世界：Class 对象与 Klass 模型

要理解反射，必须先打通前置知识：Java 类在虚拟机内部到底是什么样子的？（详见 JVM 内存模型相关文章）

Java 对象和类元数据生存在两个不同的「世界」里：

• C++ 的世界（元空间 Metaspace）：JVM 使用 C++ 编写，它在底层使用一个叫 InstanceKlass 的数据结构来存储类的所有真实元数据（比如常量池、方法表 vtable、字段布局）。这是虚拟机自己用的数据结构，Java 代码无法直接碰触。

  延伸阅读：为什么设计图要放在元空间，交由 C++ 本地内存管理？
  InstanceKlass 是底层 C++ 执行引擎（如方法分发、JIT 编译）高频读取的“基础设施”。如果把它当成普通 Java 对象放在 Java 堆中，Java 的垃圾回收（GC）在进行并发标记清理时，经常会将对象“搬家”（内存复制/整理）。这会导致 C++ 底层指向它的硬指针频繁失效，造成灾难。因此，在 JDK 8 之后，这些元数据被彻底移出虚拟机的内存划分，放入由 C++ 直接使用操作系统本地内存（Native Memory）进行管理的元空间（Metaspace）。这不仅保证了底层引擎访问的绝对稳定与极速，还打破了往昔永久代（PermGen）的容量天花板。

• Java 的世界（堆 Heap）：这是 Java 程序员生活的区域。

那么，Java 程序员该如何去读取元空间里那个遥远的 InstanceKlass 呢？

比喻时刻：

InstanceKlass 就像是建筑局保密档案室里的大楼原始设计图（保存在元空间，极其复杂且只有内部工程师能看懂）。 为了让来宾也能了解大楼的情况，大楼的接待大厅（Java 堆）里放了一本精美的印刷宣传册，上面清晰地列出了大楼有几层、几个房间、几个门廊。这本宣传册，就是 java.lang.Class 对象。

镜像关系（Mirror）

当类加载器（ClassLoader）将一个 .class 文件加载进内存时，它会做两件事：

1. 在元空间（Metaspace）创建一个对应的 InstanceKlass（设计图）。
2. 在 Java 堆（Heap）中马上创建一个 java.lang.Class 类的实例（宣传册），称为镜像（Mirror）。

在 C++ 底层，InstanceKlass 持有一个指向 Java 堆中 Class 对象的指针（java_mirror）；而在 Java 堆中，Class 对象也有一条隐秘的通道（通过底层的机制）能够读取到元空间的真实数据。

我们的所有反射操作（如 clazz.getMethods()），本质上就是拿着这本宣传册查阅，而底层则是 JVM 顺藤摸瓜去元空间提取真实的数据。

3. 深入 Class 源码：昂贵的反射与重重缓存

知道了上述原理后，我们来看看平常最常用的方法：获取一个类的方法列表。

Class<?> clazz = String.class;
Method[] methods = clazz.getDeclaredMethods();

调用 getDeclaredMethods() 看似只是获取一个数组，但在底层，它触发了一场昂贵的跨界之旅。因为这要求 JVM 深入元空间（C++ 世界），解析原始的元数据，然后把它们构造成 Java 世界的 Method 对象数组。如果每次调用都这么干，性能会极度拉垮。

因此，java.lang.Class 源码中引入了一套非常深度的缓存机制：ReflectionData。

3.1 源码解析：ReflectionData

在 OpenJDK 的 java.lang.Class 源码中，隐藏着一个私有的静态内部类 ReflectionData：

// java.lang.Class 源码（简化版）
public final class Class<T> {
    
    // 缓存反射数据（软引用）
    private transient volatile SoftReference<ReflectionData<T>> reflectionData;

    // 内部类 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;
        // ...
        final int redefinedCount;
    }
    //...
}

当你第一次调用 getDeclaredMethods() 时：

1. JVM 发现 reflectionData 为空，于是下沉到 Native 层（C++）。
2. 在元空间的 InstanceKlass 结构中提取出方法列表。
3. 实例化对应的 java.lang.reflect.Method 对象。
4. 将这些对象打包塞进 ReflectionData 内部的 declaredMethods 字段中。
5. 返回给调用者。

后续再调用时，直接从 ReflectionData 中返回缓存好的数据。

3.2 为什么用 SoftReference（软引用）？

你可能注意到 ReflectionData 是被 SoftReference 包裹的。 这是因为绝大多数运行时应用，一旦它反射过一次，通常就不再频繁反射了，或者框架（如 Spring）会在自己的层级把这些反射数据再次缓存。

如果 JVM 长时间将所有类的反射数据都强引用常驻内存，会造成极大的内存浪费。软引用的特性是：只要内存充裕，垃圾回收器就不会动它；一旦 JVM 内存快要濒临 OutOfMemoryError 时，GC 就会无情地把这些 ReflectionData 全部扫地出门，回收内存保命。万一下次又需要反射？大不了再下沉到 C++ 侧重新查一次。

3.3 classRedefinedCount 是什么？

ReflectionData 结构中有一个特殊的 final int redefinedCount 字段。 这是用来应对 热更新 / 热加载（Hot Swap） 的。Java 提供 了 Instrumentation API（如各类 Arthas、JRebel 工具），可以在程序运行时动态替换大楼的设计图（替换类的字节码）。

如果类的方法被动态增删了，大厅里的宣传册（ReflectionData 缓存）就成过期的废纸了。Class 对象中维护着一个 classRedefinedCount 计数器，只要类发生重定义，计数器加 1。获取缓存时，会对比这个 count。一旦不一致，立刻作废旧缓存，重新读取。

4. Method.invoke 的微观魔法：反射膨胀（Reflection Inflation）

拿到 Method 对象后，核心操作必然是执行它：

Method greetMethod = Person.class.getMethod("greet", String.class);
greetMethod.invoke(personObj, "Alice");

invoke() 是不是直接跳转到该方法的机器码执行？错！这里藏着 Java 源码中最精妙的机制之一：反编译膨胀阈值 15。

4.1 MethodAccessor 的委托策略

点开 Method.invoke() 源码，你会发现它并不干活，而是把工作全抛给了一个名为 MethodAccessor 的执行器：

// Method.java 源码片段
public Object invoke(Object obj, Object... args) {
    MethodAccessor ma = methodAccessor; // 获取执行器
    if (ma == null) {
        ma = acquireMethodAccessor(); 
    }
    return ma.invoke(obj, args);
}

一开始，这个 MethodAccessor 的具体实现叫 DelegatingMethodAccessorImpl，而它内部又包裹着一个 NativeMethodAccessorImpl。 整个调用链路是：Method -> Delegating -> Native -> JNI (C++ 代码)。

这种初始阶段的策略叫 Native 调用。它通过 JNI 跨过 Java 边界，去 C++ 世界按照原始指针强行执行对应的指令。

Native 调用的优缺点：

• 优点： 零预热，直接干！不需要任何初始化耗时。
• 缺点： 每次都要穿透 JNI 边界，参数还得进行转换，性能很差。被 JIT 编译器彻底无视（无法做内联优化）。

4.2 第 15 次调用：通关升华（Inflation）

如果你不停地通过反射调用同一个方法（在循环中调用了一万次），JVM 会不会傻呼呼地一直走低效的 Native 路径？不会。

NativeMethodAccessorImpl 内部有一个计数器：numInvocations。 每次被调用，计数器都加 1。当它达到一个名为 InflationThreshold 的阈值时（默认值为 15），JVM 的态度变了。

JVM 说：“看起来你很喜欢调用这个方法，老走 JNI 跨界太慢了，我干脆在运行时为你动态生成一段专属的 Java 字节码，帮你直接调用吧！”

此时发生的现象叫作 反射膨胀（Reflection Inflation）。

1. JVM 会启动底层的 MethodAccessorGenerator。
2. 动态生成一个全新的、肉眼看不见的 Java 类，名字类似于 GeneratedMethodAccessor<N>。这个新类里只有一小段字节码：它将你传入的 Object 强转为 Person，然后使用标准普通的字节码指令 invokevirtual 触发真实的 greet() 方法。
3. DelegatingMethodAccessorImpl 不再把活儿交给 Native 了，而是把代理对象替换成了这个新生成的专属类。

比喻解析：

假设你需要看懂一份法文的材料（目标方法）： 前 15 次看：你自己不懂法文，每次都要打国际长途找底层的「法文翻译官（Native JNI）」帮你读。长途电话的接通和等待特别费时间。 第 16 次看：翻译官怒了，他连夜亲自编写了一本针对这份文档的专属「中法字典小程序（Generated 字节码）」，塞给你。以后你直接用这本字典查（普通方法调用），再也不用打国际长途了。性能原地起飞！

（注：从 Java 18 开始，JEP 416 取代了这套古老的 15 次膨胀机制，转而底层基于 MethodHandles 实现。但核心思想——将昂贵的动态分发转化为可被 JIT 编译器优化的形式——始终一致。）

5. 反射的性能为何让人诟病？

所有的 Java 资料都会告诉你：反射很慢。但读到底层的你应该能具体列出它慢在哪里了：

1. 寻址成本：普通的 p.sayHello() 在编译成字节码时早就绑死了常量池引用，而 getMethod("sayHello") 需要在运行时遍历 ReflectionData 的大号数组做字符串的比对。
2. 安全检查：反射每次在 invoke 的时都会进行繁琐的安全权限校验（checkAccess），判断你有没有权限调用该私有方法。这也是为什么频繁反射调用时，我们会常写 method.setAccessible(true)——除了突破私有约束外，它还能直接禁用安全检查步骤，提升少许性能。
3. 参数装箱拆箱：Method.invoke(Object obj, Object... args) 的参数是 Object[]。如果你的方法入参是基本类型 int，底层就必须在栈中偷偷将其封箱成 Integer；返回值如果是 int，也得装成 Integer 返回，多创建了一大堆短暂的对象碎片，增加 GC 压力。
4. JIT 优化的缺失：即便第 16 次膨胀成了正常的 Java 代码，但由于参数永远是 Object[] 神仙下凡般的强转栈帧，JIT 编译器（如 C2）极难跨越这条动态鸿沟对代码进行方法内联等极致优化。

6. 核心总结

1. 元数据的阶梯：反射的源头是元空间中的 InstanceKlass（设计图），它是绝对不能碰触的禁区；而反射的核心入口 java.lang.Class（宣传册），是这个图纸在 Java 堆的替身。
2. 多级缓存：因为跨界提取元信息代价高昂，java.lang.Class 拥有由 SoftReference 守护的 ReflectionData 软引用缓存组，用它来在 OutOfMemory 的危险边缘舞步般平衡性能与内存。
3. 调用的进化：前 15 次的 Method.invoke() 会走低效的 Native-JNI 道路获取极佳的启动速度，直到第 16 次触怒 JVM，它便以空间换时间，膨胀孵化出直接在 Java 虚拟机内狂飙的特种汇编字节码门徒。

理解了这些，当你再次在 Spring 框架里盯着一大串带有 DelegatingMethodAccessorImpl 和 GeneratedMethodAccessor 字眼的异常栈（StackTrace）时，一定能会心一笑。