反射调用比直接调用慢10倍以上，核心在于JVM层动态查元数据、权限检查、参数校验及无法内联；高频路径须缓存Method/Field，优先用MethodHandle或成熟框架替代手写反射。
反射调用比直接调用慢10倍以上，核心原因在JVM层
不是代码写得“不够优雅”，而是JVM对反射的处理天生带开销：每次 Method.invoke() 都要动态查元数据、做访问权限检查、校验参数类型、绕过内联优化。JIT编译器根本没法把反射调用编译成高效机器码——它连目标方法在哪儿都不知道，更别说内联了。
常见错误现象：Method.invoke() 在循环里反复调用同一方法，结果CPU热点全堆在 ReflectionFactory.newMethodAccessor() 上；或者用 Class.forName("xxx") 加载类频繁触发类加载和验证，拖慢启动速度。
- 不要在高频路径（如Netty handler、JSON序列化循环）中无缓存地调用反射
- 避免用
getDeclaredMethods()遍历再find，改用getDeclaredMethod("setName", String.class)精准获取 -
setAccessible(true)虽能跳过部分安全检查，但首次调用仍需生成代理Accessor，且破坏模块封装，慎用
缓存Class/Method/Field对象是性价比最高的优化
反射慢，主要慢在“找东西”的过程，而不是“调东西”。Class.forName()、getDeclaredMethod() 这些操作内部涉及字节码解析、符号引用解析、权限树遍历，平均耗时是纳秒级→微秒级，但积少成多。
实操建议：用 ConcurrentHashMap 缓存关键反射元数据，键为 Class + 方法名 + 参数类型数组，值为 Method 实例。Spring、Jackson 都这么干。
立即学习“Java免费学习笔记（深入）”；
private static final Map<String, Method> METHOD_CACHE = new ConcurrentHashMap<>();
// key 示例："com.example.User#setId#java.lang.Long"
String key = cls.getName() + "#" + methodName + "#" + Arrays.toString(paramTypes);
Method method = METHOD_CACHE.computeIfAbsent(key, k -> {
try {
return cls.getDeclaredMethod(methodName, paramTypes);
} catch (NoSuchMethodException e) {
throw new RuntimeException(e);
}
});
- 别缓存
Class.forName()结果——它本身已由JVM缓存，重复调用开销极小 - 缓存
Field时注意：如果字段是final或被JIT优化为常量，反射写入可能失效 - 缓存粒度宁细勿粗，比如按
getter/setter分开缓存，避免因泛型擦除导致类型误匹配
Java 7+ 推荐用 MethodHandle 替代 Method.invoke()
MethodHandle 是JVM原生支持的轻量级调用机制，不走反射的完整安全检查链路，可被JIT深度优化（甚至内联），性能通常比缓存后的 Method.invoke() 高2–5倍。
但它不是“反射替代品”，而是“更底层的调用抽象”：没有自动类型转换、不抛 IllegalAccessException，出错就是 WrongMethodTypeException 或 RuntimeException。
MethodHandles.Lookup lookup = MethodHandles.lookup();
MethodHandle mh = lookup.findVirtual(String.class, "length", MethodType.methodType(int.class));
int len = (int) mh.invokeExact("hello"); // 注意：invokeExact 要求参数/返回值类型完全匹配
- 只在确定调用目标稳定、且对性能极度敏感的场景用
MethodHandle（如自研序列化框架） - 别用
invoke()，坚持用invokeExact()，否则会引入适配器开销，抵消性能优势 -
MethodHandle无法访问private成员，除非通过lookup.in(cls).findSpecial(...)构造，且仍受模块系统限制
哪些场景真躲不开反射？优先选成熟库而非手写
不是所有反射都该被消灭。框架层（Spring BeanFactory）、序列化（Jackson BeanDeserializer）、动态代理（Proxy.newProxyInstance）这些地方，反射是架构刚需。问题在于：你自己写的那几行 field.set(obj, value) 很可能早就有更稳更快的轮子。
例如给POJO赋值，别手撸反射循环设字段，改用：
-
org.springframework.beans.BeanWrapperImpl（支持嵌套属性、类型转换） -
net.sf.cglib.beans.BeanMap.create(obj)（生成字节码，零反射开销） - Jackson 的
ObjectMapper.convertValue()（已内置字段缓存和MethodHandle回退）
真正容易被忽略的点：模块化（JPMS）下，setAccessible(true) 在默认 opens 不足的模块里会直接失败，报 InaccessibleObjectException——这跟性能无关，但会让反射代码在JDK9+上静默崩溃。
