反射调用 Method.invoke() 比直接调用慢 10–100 倍，主因是 JVM 无法内联、运行时类型检查、每次权限校验及参数数组包装；setAccessible(true) 可提速 20–40% 但破坏封装且受模块系统限制；缓存 Method/Field 对象最有效；替代方案包括接口工厂、MethodHandle、VarHandle 和字节码生成。
反射调用 Method.invoke() 比直接调用慢多少？
不是“慢一点”，而是可能慢 10–100 倍，尤其在高频调用场景下。根本原因在于：JVM 无法对反射调用做内联（inlining）、类型检查推迟到运行时、每次调用都要校验访问权限、还要包装参数为 Object[] 数组。
- 直接调用
obj.doSomething(123)：编译期绑定，JIT 后几乎无开销 - 反射调用
method.invoke(obj, 123)：每次都要查方法表、检查Accessible、拆箱/装箱、异常封装（即使没异常也要准备InvocationTargetException） - 实测：空方法体下，反射调用吞吐量常不足直接调用的 15%
为什么 setAccessible(true) 能提速但仍有隐患？
它绕过 Java 访问控制检查（比如 private 字段读写），省掉一次安全校验，通常能提升 20–40% 的反射操作速度。但代价是：
- 破坏封装性，使代码依赖内部实现细节，类结构一变就崩
- 某些安全策略（如
SecurityManager已废弃但仍有遗留环境）会直接拒绝该操作，抛出SecurityException - JDK 9+ 模块系统下，跨模块设
setAccessible(true)默认失败，需显式加--add-opens参数，否则抛InaccessibleObjectException
缓存 Method / Field 对象有用吗？
非常有用——这是最简单有效的优化手段。反射元对象（Method、Field、Constructor）本身是线程安全且可复用的，查找过程（clazz.getDeclaredMethod(...)）才是重头开销。
Map<String, Method> methodCache = new ConcurrentHashMap<>();
// 首次查找并缓存
Method m = clazz.getDeclaredMethod("getName");
m.setAccessible(true);
methodCache.put("getName", m);
// 后续直接用
m.invoke(obj); // 不再走 getDeclaredMethod
- 避免重复解析方法签名、遍历声明方法列表
- 注意：缓存 key 要包含参数类型（如
"getName:()Ljava/lang/String;"），否则重载方法会冲突 - 不要缓存
invoke()结果，那不是元数据，是执行行为
有没有比反射更快的替代方案？
有，但要看场景。纯性能优先时，优先考虑：
立即学习“Java免费学习笔记（深入）”；
- 接口 + 工厂：让被调用类实现统一接口，用
ServiceLoader或 Spring Bean 查找，零反射开销 -
字节码生成（如
ByteBuddy或CGLIB）：在运行时生成代理类，首次生成稍慢，后续调用等同直接调用 - JDK 7+ 的
MethodHandle：比Method.invoke()快不少（约 2–3 倍），且支持更精细的权限控制，但 API 更底层、调试困难 - 记录类（
record）+VarHandle（JDK 9+）：对字段访问特别快，接近直接字段访问，但仅限 public 字段或配合setAccessible
真正麻烦的是那些必须绕过编译期类型约束的场景——比如通用 ORM 的属性映射、JSON 反序列化。这时候反射不是“选不选”的问题，而是“怎么控”：缓存、降频、隔离热路径、必要时 fallback 到代码生成。
