Java 的反射性能优化？

反射性能优化的核心不是"少用反射"，而是把查找和访问检查从热路径上挪走：先缓存 Method/Field/Constructor 对象，再 setAccessible(true)，仍不够就升级到 MethodHandle 或 LambdaMetafactory 生成函数式接口。做到前两步，反射开销通常能从每次调用 100 纳秒级降到 10 纳秒级；做到第四步，可以逼近直接调用。

反射到底慢在哪一步？

结论：反射的开销主要花在 getDeclaredMethod 的查找和 invoke 的访问检查、参数装箱上，而不是"调用"这个动作本身。

Class.getDeclaredMethod(name, types) 每次调用都要遍历方法表、比对参数类型、复制一份新的 Method 对象，并且做安全校验；Method.invoke(Object, Object...) 每次要把参数塞进一个新建的 Object[]，基本类型要装箱（int → Integer），还要做可见性检查。这三件事都是 O(1) 但有固定成本，放进百万次循环就是灾难。

结论：JDK 8 到 JDK 17 的反射有"膨胀"（inflation）机制，同一个 Method 前 15 次调用走 native 实现，之后才生成字节码访问器；JDK 18（JEP 416）改用 MethodHandle 重写核心反射，这套阈值机制被移除。

反射性能优化怎么做？按收益排四档

结论：四档方案的收益从低到高是——缓存 Member 对象 < setAccessible(true) < MethodHandle < LambdaMetafactory；前两档改动成本接近零，任何项目都应该先做。

第一档：缓存。 把 Method、Field、Constructor 提取到 static final 常量，或者放进 ConcurrentHashMap<Class<?>, Map<String, Method>>。这一步能把 getDeclaredMethod 的查找开销从每次调用中彻底移除。

第二档：跳过访问检查。 调用 method.setAccessible(true)（JDK 9+ 用 trySetAccessible() 判断是否成功）。它省掉每次 invoke 的可见性校验，是性价比最高的一行代码。

第三档：MethodHandle。 用 MethodHandles.lookup().findVirtual(cls, name, methodType) 拿到句柄，把 MethodHandle 声明成 static final 常量并配 invokeExact 调用——static final 的句柄会被 JIT 当常量折叠，这是反射做不到的。

第四档：LambdaMetafactory。 用 LambdaMetafactory.metafactory(...) 在运行时生成一个函数式接口实现，之后每次调用就是一次 invokeinterface，JIT 可以内联。这是"保留反射灵活性、拿到接近直接调用性能"的方案，Spring 6、MyBatis 的部分映射器都走这条路。

缓存 Method 对象能提升多少？

结论：在 JDK 17 + JMH 下，同一方法调用 1000 万次，量级参考如下——直接调用 1~2 ns/op；缓存 Method + setAccessible 后 invoke 约 5~10 ns/op；不缓存、每次 getDeclaredMethod 再 invoke 约 150~300 ns/op；LambdaMetafactory 生成的接口调用约 2~3 ns/op。

也就是说，只做"缓存 + setAccessible"就能拿到 20~30 倍提升，剩下的是从 10 ns 压到 2 ns 的活儿。是否值得继续优化，看你的调用频次：每秒 1 万次调用，10 ns 和 2 ns 的差别是每秒 80 微秒，直接忽略。

setAccessible(true) 在 JDK 17 上还能用吗？

结论：能用，但必须在模块开放的前提下，否则抛 InaccessibleObjectException。

JDK 9 引入模块系统（JPMS）后，跨模块反射 java.base 里的私有成员需要显式开洞，例如启动参数加 --add-opens java.base/java.lang=ALL-UNNAMED。三个注意点：一是 setAccessible 破坏封装，某些 JVM 版本的 final 字段不保证立即可见；二是对 record 组件和 String 内部字段这类强封装目标，JDK 17 会直接拒绝；三是优先用 trySetAccessible() 而不是 setAccessible()，避免在受限环境抛异常中断流程。

MethodHandle 和反射有什么区别，该选哪个？

结论：反射是"运行时元数据查询"，MethodHandle 是"类型化的可执行引用"；前者 JIT 无法内联，后者可以。

MethodHandle 的关键在于签名多态：invokeExact 要求调用点的静态类型与句柄类型完全一致，不一致直接抛 WrongMethodTypeException；invoke 会做类型适配但慢一些。所以正确姿势是把句柄存成 static final 常量、用 invokeExact。如果调用点类型在编译期确定不了，MethodHandle 的优势会大打折扣，此时不如直接用 LambdaMetafactory 生成接口。

什么时候不该优化反射

结论：单次请求里反射调用占比低于 1%、或者每天总调用量在百万级以下，做"缓存 + setAccessible"就够，继续往下优化是负收益。

判断方法很朴素：用 async-profiler 或 JFR 采样，看 Method.invoke 在火焰图里占的宽度。占不到 3% 的，优化它不如优化一次 SQL。反射真正的价值是解耦，把框架层写成零反射通常意味着牺牲扩展性，这个交换要慎重。

一句话收束：反射优化的顺序永远是"缓存 → 跳过访问检查 → MethodHandle → 代码生成"，先测量再动手，别一上来就上 ASM。