java反射性能损耗主要来自方法查找、安全检查、装箱拆箱和jit无法优化四环节；实测未缓存method调用比直接调用慢63.1倍，其中70%耗时在重复查找；优化关键为缓存method、一次setaccessible、高频场景改用methodhandle。
Java 反射机制的性能损耗不是“有没有”，而是“有多大、在哪发生、能不能收住”。评估要落到具体调用链上，优化则重在切断重复开销——它不靠换语言或重写逻辑，而靠对 JVM 运行机制的理解和几处关键动作。
性能损耗主要来自这四个环节
反射慢，不是因为代码写得不够漂亮，而是 JVM 在运行时被迫多做了很多事：
-
方法查找是线性扫描：每次调用
getMethod("xxx", String.class)，JVM 都要遍历当前类及其父类的方法表，匹配名称和参数类型。没缓存就是 O(n)，且无法复用 -
每次 invoke 都做安全检查：哪怕方法是 public，JVM 仍要校验调用栈是否有权限；私有成员调用
setAccessible(true)更会触发安全管理器介入，甚至修改类元数据结构 - 参数和返回值强制 Object 包装：传 int 会自动装箱为 Integer，取回再拆箱，一次调用多出两层对象创建与 GC 压力
- JIT 编译器基本放弃优化：Method.invoke() 是动态分派，目标方法不固定，无法内联、无法去虚化、逃逸分析失效，长期停留在解释执行路径
真实耗时对比：别只看比例，要看绝对值
在 JDK 17 下对一个简单 getter 方法做基准测试（百万次调用）：
| 调用方式 | 平均单次耗时 | 相对直接调用 |
|---|---|---|
直接调用 obj.getName()
|
2.3 ns | 1x |
| 反射调用（缓存 Method + setAccessible） | 35.8 ns | 15.6x |
| 反射调用（未缓存 Method） | 145.2 ns | 63.1x |
注意：63 倍差距里，约 70% 耗在重复查找 Method 上。也就是说，**查方法比调方法还慢**。
立竿见影的三项优化动作
不需要改架构、不引入新框架，加几行代码就能把反射从“明显拖慢”拉回“可接受范围”：
-
必须缓存 Method/Field/Constructor 实例：用
ConcurrentHashMap存，key 可用clazz.getName() + "#" + methodName + "(" + Arrays.toString(paramTypes)拼接；首次获取后复用，彻底避免重复查找 - setAccessible(true) 只设一次，且与反射对象一起缓存：不要每次 invoke 前都调一遍；缓存前就设好，后续直接 invoke，跳过权限校验路径
-
高频场景优先迁移到 MethodHandle：JDK 7+ 提供，语义类似反射但底层更轻量，支持 JIT 内联；例如：
MethodHandle mh = lookup.findVirtual(User.class, "getName", methodType(String.class))，调用速度接近直接调用
什么情况下该换方案，而不是硬优化反射
当反射出现在以下位置，说明设计已越界，优化收益有限，该考虑替代方案：
-
业务核心循环体内反复反射调用：比如 for 循环里每次都
obj.getClass().getMethod(...).invoke(...)—— 这不是性能问题，是架构信号 - 同一类结构已完全可知，却仍用反射读写字段：如 DTO 转 VO，字段名和类型固定，用 BeanUtils 或手动映射更稳更快
- 需要极致吞吐或低延迟的模块（如网关、风控引擎）：应采用字节码生成（ByteBuddy / ASM）或编译期注解处理器（APT），把“运行时反射”提前到“加载时生成”
不复杂但容易忽略。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
