反射底层实现：从Native方法深入探讨JVM的Reflection.c源码

林译川

2026-10-06 • 👁 0人浏览过

Java反射底层依赖JVM的C语言实现，核心是HotSpot中src/share/vm/prims/Reflection.c文件，它作为Java反射API与JVM内部结构（如Klass、Method）之间的安全桥接层，负责参数校验、类型转换和请求分发，不直接执行反射语义逻辑。 Java反射的底层并非纯Java实现，而是大量依赖JVM内部的C语言代码，其中最关键的一环就是

Reflection.c

——位于HotSpot源码

src/share/vm/prims/

目录下的本地方法桥接文件。它不直接处理反射逻辑，而是作为Java层

java.lang.reflect

类（如

Method

、

Field

、

Constructor

）与JVM运行时服务之间的“翻译官”，把高层反射调用转为对JVM内部数据结构（如

Klass*

、

Method*

、

FieldInfo

）的安全访问。 Native方法如何触发Reflection.c中的逻辑 Java反射API中几乎所有关键操作都声明为

native

，例如：

private static native Method[] getDeclaredMethods0(boolean publicOnly)

（定义在

Class.java

）

private native Object invoke0(Method m, Object obj, Object[] args)

（定义在

Method.java

）这些方法在JVM启动时通过

JNI_RegisterNatives

机制绑定到

Reflection.c

中对应的C函数，比如

JVM_GetDeclaredMethods

或

JVM_InvokeMethod

。真正执行时，JVM会跳转至

Reflection.c

里的C函数体，开始操作HotSpot内部对象。 Reflection.c的核心职责：参数校验与上下文转换它本身不做反射语义的完整实现（如方法查找、访问控制检查、字节码解析），而是聚焦三件事：安全拦截：检查调用方是否具备

ReflectPermission("suppressAccessChecks")

，决定是否绕过Java语言级访问限制类型转换：把Java层传入的

java.lang.Class

对象转为C++侧的

Klass*

指针，把

java.lang.reflect.Method

实例解包为内部

Method*

结构体委托分发：将请求转发给更底层模块，例如调用

Reflection::invoke_method

（在

reflection.cpp

中）完成实际调用，或调用

InstanceKlass::methods()

获取方法列表一个典型流程：Method.invoke()到底发生了什么以

method.invoke(obj, args)

为例，简化后的调用链如下： Java层

Method.invoke()

→ 调用

invoke0()

（native） JVM跳转至

Reflection.c

中的

JVM_InvokeMethod

做参数合法性检查（如目标对象是否匹配声明类）、权限判断、准备调用上下文调用

Reflection::invoke_method

（

reflection.cpp

），该函数进一步调用

JavaCalls::call()

进入解释器或即时编译器执行路径最终由JVM执行引擎真正运行目标方法的字节码（可能触发栈帧创建、参数压栈、异常处理等）可见，

Reflection.c

是反射调用的“守门人”和“调度器”，而非“执行者”。它的代码量不大（约千行），但位置关键——所有反射入口都经此中转。为什么不能绕过Reflection.c直接调用JVM内部API HotSpot严格区分“外部可调用接口”与“内部实现细节”。

Reflection.c

暴露的

JVM_*

函数是JVM规范定义的稳定JNI入口；而

Klass

、

Method

等C++类属于内部实现，其内存布局、字段顺序、生命周期管理随时可能变更。直接在Java层或第三方Agent中硬编码访问这些结构，极易导致崩溃或未定义行为。这也是为何JDK 9+引入模块系统后，

sun.misc.Unsafe

和反射绕过检查的能力被持续收紧——本质是在加固

Reflection.c

这道防线。

相关文章