方法引用本身不慢，但反射调用链导致性能断崖下跌；真正影响性能的是调用方式而非声明方式，只有MethodHandle.invokeExact()或VarHandle/Unsafe等绕过反射语义的路径才能接近直接访问性能。
方法引用本身不慢，但一旦进入反射调用链，性能就会断崖式下跌——不是语法问题，而是JVM执行路径被彻底重构。
方法引用在反射中实际不生效
Java里写::得到的是MethodHandle或函数式接口实例，但若后续仍走Method.invoke()，那这个“引用”只是表层语法糖，底层依然触发完整反射流程。真正起作用的是调用方式，不是声明方式。
- 用
obj::methodName生成的Consumer，再通过invoke执行，仍需查Method对象、做安全检查、装箱参数 - 只有直接调用
MethodHandle.invokeExact()，才可能跳过部分校验，获得JIT内联机会 -
VarHandle（JDK 9+）或Unsafe字段操作，才是真正绕开反射语义的变量访问路径
变量访问速度受反射拖累的核心环节
字段读写看似简单，但反射让每次Field.get()都变成一次微型解析任务：
- 每次都要重新计算字段在对象内存中的偏移量，无法像普通字段访问那样固化为一条
mov指令 - 即使
setAccessible(true)，首次调用仍要生成GeneratedMethodAccessor，加载类、验证字节码、等待JIT编译就绪 - 传入的
Object参数必须拆箱/类型转换，而直接访问user.age是纯栈上操作，无对象创建开销
实测对比能看清差距本质
同一字段读取，在HotSpot JVM（JDK 17+）下典型耗时：
- 直接访问
public int age：约2–3 ns - 反射
field.get(obj)（已缓存Field + setAccessible）：约250–300 ns - 未缓存
clazz.getDeclaredField("age")再get：单次超1000 ns，循环中会触发GC压力飙升
百倍差异不是误差，是解释执行 vs 硬编码内存寻址的本质区别。
真正有效的优化不是“怎么写”，而是“换条路走”
想保住灵活性又不牺牲性能，关键在于避开反射主干道：
- 用
MethodHandles.lookup().findGetter(cls, "age", int.class)获取句柄，它比Field更轻，部分场景可被C2编译器内联 - 对DTO类等结构稳定场景，用
VarHandle（配合Lookup.findVarHandle），访问延迟压到10 ns内 - 序列化/ORM框架内部可用
sun.misc.Unsafe或JVMCI生成字节码，把反射逻辑编译成原生字段访问指令 - 避免在Netty handler、RPC反序列化等高频路径中保留
Method.invoke()，哪怕已缓存
