method.invoke() 慢主因是jvm保护性降级：访问检查、参数封装、类型擦除转换及无法充分内联；缓存method、setaccessible(true)、改用methodhandle或模块opens可优化。
反射调用 Method.invoke() 为什么比直接调用慢十倍以上
核心原因不是反射本身，而是 JVM 对反射路径的保护性降级：每次 Method.invoke() 都会触发访问检查（SecurityManager 检查）、参数数组封装、类型擦除后的适配转换，且无法被 JIT 充分内联。实测在 HotSpot 上，未预热时可能慢 20–50 倍；即使预热后，仍比直接调用慢 5–10 倍。
实操建议：
- 对高频调用场景（如序列化框架、DI 容器），务必缓存
Method实例，并调用setAccessible(true)跳过访问检查——但仅在确定类加载器可信的前提下使用 - 避免在循环内反复调用
Class.getDeclaredMethod()，应提前获取并复用Method - JDK 9+ 可考虑用
MethodHandle替代：它支持更激进的 JIT 优化，且MethodHandle.invokeExact()开销接近直接调用（需严格匹配签名）
模块系统（JPMS）下 IllegalAccessException 的真实来源
JDK 9 引入模块系统后，setAccessible(true) 不再万能。即使关闭了安全管理器，若目标类所在模块未通过 opens 或 exports 显式开放包给你的模块，Method.setAccessible(true) 会静默失败，随后 invoke() 仍抛 IllegalAccessException。
实操建议：
- 检查模块描述符（
module-info.java）中是否包含类似opens "com.example.internal" to my.module;的声明 - 运行时可通过
--add-opens java.base/java.lang=ALL-UNNAMED临时放宽限制（仅限调试或遗留系统迁移） - 生产环境应优先重构为服务接口 + SPI，而非强行反射跨模块私有成员
Android 上 ReflectionUtils 类型擦除导致的 NoSuchMethodException
Android 的 Dalvik/ART 在泛型擦除上更激进，且 R8/ProGuard 默认移除桥接方法（bridge methods）。当你反射调用一个泛型方法（如 <t> T get(String key)</t>），实际编译后生成的桥接方法名可能是 get，但签名已变为 Object get(String)。若未保留桥接方法，getDeclaredMethod("get", String.class) 就会失败。
实操建议：
- 在
proguard-rules.pro中添加：-keepclassmembers class * { *** bridge*(...); } - 改用
getDeclaredMethods()遍历匹配，按返回类型和参数数量辅助判断，而非只依赖方法名 - Android 8.0+ 可尝试
ReflectiveOperationException捕获后 fallback 到java.lang.invoke.MethodHandles.Lookup（需 API 26+）
如何判断某处反射是否真有必要——三个硬性检查点
反射不是“写起来方便”，而是“别无选择”。以下任一不满足，就该放弃反射：
- 目标类与调用方不在同一 ClassLoader，且无法通过统一接口或 SPI 解耦
- 需要访问的成员是
private或package-private，且无法推动上游增加public访问层（如测试工具除外） - 动态行为必须基于运行时未知的类名/方法名（如插件系统加载外部 jar），而非仅用于简化 if-else 分支
多数所谓“通用 DAO”或“自动映射工具”里的反射，其实只是把编译期可确定的逻辑拖到了运行时——这类代码往往在压测时暴露出 GC 压力和 JIT 编译延迟问题，且难以 debug。
