必须用反射，因为框架需在运行期动态处理编译期未知的类名、方法签名和注解（如spring不知userservice、mybatis不知usermapper），jvm通过元空间中class对象暴露元数据；class.forname触发类加载，getdeclaredmethod读取方法表，invoke经jni调用methodaccessor并可能jit优化；性能代价在于权限校验、类型匹配及阻碍内联，故spring等框架缓存method并结合methodhandle优化。
大厂面试中，反射机制的追问往往不满足于“能做什么”，而是直击底层设计逻辑和工程权衡。回答时要跳出 API 列举，从 JVM 运行机制、框架真实需求、性能代价三个维度展开，才能体现深度。
为什么必须用反射？编译期和运行期的信息断层
Spring 不知道你写的是 UserServiceImpl，MyBatis 不知道你的 UserMapper 接口里有个 selectById 方法。这些类名、方法签名、注解配置，全在应用启动后才由配置文件、注解扫描或 XML 解析出来。JVM 加载类时会把元数据（字段、方法、泛型、注解）存进元空间，Class 对象就是访问这堆元数据的唯一句柄。没有反射，框架就只能写死类型，彻底失去通用性。
面试官常问的底层链路：Class.forName 到 invoke 到底发生了什么
这个过程不是黑盒：
- Class.forName("com.example.User")：触发类加载器加载字节码，解析并注册 Class 对象到 JVM 元空间；
- clazz.getDeclaredMethod("getName")：从元空间中读取该类的方法表，构造 Method 实例（它本身不包含执行逻辑，只是元数据快照）；
- method.invoke(obj, null)：JVM 内部通过 JNI 调用 MethodAccessor，首次调用会生成委派类（如 DelegatingMethodAccessorImpl），后续可能被 JIT 编译为本地代码——这也是为什么第一次反射慢、多次后变快。
性能与安全怎么平衡？不能只说 setAccessible(true)
setAccessible(true) 只是绕过 Java 的访问控制检查，并不提升字节码解析速度。真正影响性能的是：
- 每次反射调用都要做权限校验、参数类型匹配、异常包装；
- Method/Field 对象未缓存时，重复 getDeclaredMethod 会反复查表；
- 频繁反射调用会阻碍 JIT 内联优化。
所以 Spring 等框架实际做法是：缓存 Method 和 Constructor 对象，配合 Unsafe 或 MethodHandle（Java 7+）做进一步优化，而不是裸用反射。
框架里哪些地方真正在用反射？别只背名字
光说“Spring 用了反射”没用，要讲清具体环节：
- Bean 实例化：根据 @Component 扫描到的类名，用 Class.forName + 构造器反射创建对象；
- 依赖注入：遍历字段上的 @Autowired，用 Field.set() 注入实例；
- Mapper 接口代理：MyBatis 为 UserMapper 生成代理类，内部通过反射调用对应 XML 中的 SQL 方法；
- JSON 序列化：Jackson 用 getDeclaredFields() 扫描所有字段（含 private），再通过 Field.get() 读值。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
