关键在于提前固化调用路径以剥离每次调用的类型检查开销：缓存method并调用setaccessible(true)，改用methodhandle的invokeexact()，模块下需显式opens包，高频场景优先采用编译期getter/setter或框架优化方案。
避开反射高频调用的类型检查耗时，关键不是“少用反射”，而是把开销从每次调用里彻底剥离——核心在于提前固化调用路径，让 JVM 能像调用普通方法一样处理它。
缓存 Method 并预置访问权限
每次 Class.getDeclaredMethod() 都会重新解析字节码、匹配签名、校验访问控制，这是最大开销源之一。缓存 Method 对象能跳过这一步，但仅缓存不够：
- 务必在获取后立即调用
method.setAccessible(true)，绕过运行时访问检查（注意：仅限可信类加载器环境） - 缓存键建议用
Class + 方法名 + 参数类型数组组合，避免重载冲突（别用Method.toString()） - 推荐用
ConcurrentHashMap存储，Method本身线程安全，无需额外同步
改用 MethodHandle 替代 invoke()
MethodHandle 是 JVM 原生支持的轻量级调用机制，不走反射的通用入口，JIT 可对其充分内联和优化：
- 使用
MethodHandles.lookup().findVirtual()或findStatic()获取句柄 - 调用
invokeExact()（需参数/返回值类型严格匹配），实测开销接近直接调用 - 相比
Method.invoke()，它不封装参数为 Object[]，也不做运行时类型擦除适配
模块系统下显式开放包访问
JDK 9+ 模块系统中，setAccessible(true) 不再自动生效。即使关闭 SecurityManager，若目标包未开放，仍抛 IllegalAccessException：
- 在
module-info.java中声明opens "com.example.internal" to your.module; - 调试或迁移阶段可用启动参数临时放宽：
--add-opens java.base/java.lang=ALL-UNNAMED - 避免依赖
setAccessible(true)的“静默失败”行为，运行时应主动验证句柄是否可调用
高频场景优先用编译期方案
反射是动态兜底手段，不是性能敏感路径的首选：
- 字段读写尽量用自动生成的 getter/setter 接口，或通过接口统一抽象行为
- 序列化、ORM 等框架内部已做缓存与签名归一化，优先复用 Spring 的
ReflectionUtils或ResolvableType - 对 boolean 字段等特殊类型，内省（Introspector）查找 accessor 比原始反射略快，但执行仍是反射调用——本质未变，慎用
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
