Java反射是JVM提供的标准能力，通过Class对象动态获取类型信息并调用成员，但存在性能开销与安全限制；获取Class有三种方式，访问成员需区分getDeclaredXXX与getXXX，invoke()调用有三处易错点，且反射影响JIT优化。
Java反射不是“黑魔法”，而是JVM在运行时暴露的一套标准能力——它允许程序在不编译期知道类名、方法名、字段名的前提下，动态获取类型信息并调用其成员。关键在于：所有操作都基于Class对象展开，且必须绕过编译检查，因此天然伴随性能开销和安全性限制。
Class对象怎么来：三种获取方式与适用场景
反射的起点永远是Class实例，但不同来源意味着不同约束：
-
MyClass.class：最安全，编译期校验存在性，适合已知类名且无需加载逻辑的场景（如注解处理器） -
obj.getClass()：适用于已有实例、需探查实际运行时类型（注意可能为子类），但不能用于基本类型 -
Class.forName("com.example.MyClass")：触发类加载和静态初始化，常用于配置驱动（如JDBC注册），但会抛ClassNotFoundException，且类路径错误时失败明显
别误用ClassLoader.loadClass()——它不执行静态块，且返回Class前不验证类格式，容易在后续反射调用时报NoClassDefFoundError而非更明确的异常。
getDeclaredXXX vs getXXX：访问权限差异决定你能看到什么
反射API中大量成对方法，核心区别就一条：getDeclared系列无视访问修饰符（private/protected/package-private），只看当前类声明；get系列（如getMethod）只返回public成员，且会沿继承链向上查找。
立即学习“Java免费学习笔记（深入）”；
- 想读取private字段？必须用
getDeclaredField("name")，再调用setAccessible(true)绕过访问检查（模块化后需--add-opens参数） - 调用父类public方法？
getMethod("toString")能直接拿到，但getDeclaredMethod("toString")在子类里会报NoSuchMethodException - 获取所有字段（含继承）？没有现成API，得手动遍历
getSuperclass()链并合并getDeclaredFields()
invoke()调用方法时的三个易错点
Method.invoke()表面简单，实际藏着三处高频翻车点：
- 第一个参数是目标对象（
null仅限static方法），传错类型或null非static方法会抛IllegalArgumentException - 参数数组类型必须严格匹配：传
int给Integer形参？不行，得自动装箱或显式转为Integer，否则报IllegalArgumentException（提示“argument type mismatch”） - 被调方法抛出的异常会被包装进
InvocationTargetException，必须用getCause()提取原始异常，否则日志里只看到一层包装
示例：method.invoke(obj, new Object[]{42})比method.invoke(obj, 42)更安全，避免因泛型擦除或重载导致的参数类型推断错误。
反射性能差在哪：不只是慢，还有JIT优化失效
反射慢不只是因为查表和类型转换——根本问题是JVM无法对invoke()做内联和逃逸分析。实测显示，频繁反射调用的方法，即使逻辑极简，吞吐量也可能比直接调用低10倍以上。
- 缓存
Method/Field对象能省掉查找开销，但无法解决调用本身的成本 - Java 9+ 提供
MethodHandle和VarHandle作为替代，它们可被JIT优化，但API更底层，且MethodHandle.invokeExact()要求参数类型完全一致（无自动装箱） - 框架级使用（如Spring、Jackson）通常结合字节码生成（CGLIB/ASM）规避反射，仅在首次启动时用反射做元数据扫描
真正该警惕的不是“能不能用”，而是“是否在热点路径上用了”。一次HTTP请求里反射调用几十次可能无感，但在每毫秒执行万次的计算循环里，它就是瓶颈本身。
