Class对象是JVM类加载后在元空间生成的唯一元数据镜像，封装常量池、字段偏移、方法表等信息；反射通过JNI调用JVM内部结构体（如Method*）执行，绕过字节码校验但受内存模型保护；setAccessible(true)仅关闭Java层访问检查，不改变字段语义。
面试进阶中谈反射，不能只背“运行时获取类信息”这种话。关键是要把反射和JVM类加载、内存模型、字节码机制串起来讲清楚——这正是区分初级和中级开发者的分水岭。
Class对象是反射的唯一入口，本质是JVM加载后的元数据镜像
每个类被加载进JVM后，会在元空间（JDK8+）生成且仅生成一个Class对象。它不是普通Java对象，而是JVM内部用C++实现的OopDesc子类实例，封装了该类全部结构信息：常量池索引、字段偏移量、方法表指针、访问标志、注解集合等。反射API（如getDeclaredMethods()）底层调用的就是JVM提供的JNI函数，比如jvm_GetDeclaredMethods，最终从这个Class镜像里提取数据。
所以当你写Class.forName("com.example.User")，JVM做的不只是“找类”，而是触发完整的加载→链接（验证/准备/解析）→初始化三阶段流程；而User.class则跳过加载和初始化，直接返回已存在的Class引用——这也是它性能最优的原因。
反射调用方法的本质：绕过字节码校验，直连JVM解释器或即时编译入口
普通方法调用（如obj.doWork()）在字节码层面是invokevirtual指令，由JVM在运行时查虚方法表（vtable）完成分派；而反射调用method.invoke(obj, args)会走另一条路径：
立即学习“Java免费学习笔记（深入）”；
- JVM先校验访问权限（除非setAccessible(true)，此时跳过AccessController.checkPermission）
- 将Method对象映射为JVM内部的Method*结构体，拿到字节码起始地址和参数签名描述符
- 若方法未被JIT编译，则交由解释器执行；若已编译，则通过methodOop的_entry_point跳转到native code
- 参数需经Java栈→JNI本地栈→目标方法栈帧的多次拷贝，这是性能损耗主因
为什么setAccessible(true)能突破private？这不是“破坏封装”，而是JVM层的权限开关
Java语言的访问控制（public/private/protected）在编译期写入字节码access_flags，并在类加载验证阶段被JVM记录进运行时常量池。但JVM本身并不强制执行这些限制——真正做检查的是Reflection API的Java层包装逻辑（如AccessibleObject.checkAccess()）。
调用setAccessible(true)实际是把AccessibleObject内部的override字段设为true，后续invoke/get/set就跳过checkAccess。这不修改字节码，也不影响其他代码对同一字段的正常访问，更不会让private字段变成public。它只是告诉反射框架：“这次我授权你绕过Java语言级检查”，底层仍受JVM内存模型保护（比如final字段的语义约束依然生效）。
高频陷阱题怎么答出深度：比如“反射比直接调用慢多少？”
不能只说“慢10倍”这种模糊答案。要结合JVM行为分层拆解：
- 首次调用开销大：Class查找、Method解析、安全检查、参数类型转换、JNI过渡，可能达毫秒级
- 重复调用可优化：HotSpot对反射调用有专用内联缓存（ReflectionAccessor），连续调用同Method对象时，JIT可能将其编译为接近直接调用的机器码
- 真正瓶颈在参数传递：Object[]数组包装、自动装箱拆箱、异常捕获机制（InvocationTargetException包装）比方法体执行耗时更长
所以优化方案不是“禁用反射”，而是缓存Method/Constructor引用、复用参数数组、配合VarHandle（JDK9+）或MethodHandle（更底层，支持JIT内联）替代传统反射。
