Java反射性能测试必须用JMH做可控、可比、可复现的微基准测试，对比直接调用与分层反射（缓存Method、setAccessible、参数类型等）的相对开销，并覆盖真实场景如多参、private、泛型方法及第三方库横向对比。
测Java反射调用方法的性能影响，核心是做**可控、可比、可复现**的基准测试，不能只靠“感觉”或单次执行。重点不是看绝对耗时，而是对比反射调用和直接调用之间的相对开销，同时暴露不同优化手段的实际收益。
选对工具：用JMH而不是System.currentTimeMillis()
手写for循环+毫秒计时（如System.currentTimeMillis()）误差大、受GC/上下文切换干扰严重，尤其在纳秒级差异场景下完全不可靠。必须用专业微基准测试框架JMH（Java Microbenchmark Harness）：
- 自动预热JVM（避免冷启动、解释执行拖慢结果）
- 屏蔽无关代码优化（如死码消除、常量折叠）
- 多轮采样、统计显著性（给出置信区间而非单次值）
- 支持@Fork、@Warmup、@Measurement等精细控制
示例关键结构：
@State(Scope.Benchmark)
@Fork(3) // 3次独立JVM进程
@Warmup(iterations = 5, time = 1, timeUnit = TimeUnit.SECONDS)
@Measurement(iterations = 10, time = 1, timeUnit = TimeUnit.SECONDS)
public class MethodCallBenchmark {
private Target obj;
private Method method;
@Setup
public void setup() throws Exception {
obj = new Target();
method = Target.class.getMethod("doSomething");
method.setAccessible(true); // 关闭检查，单独测这部分影响
}
@Benchmark
public void direct() {
obj.doSomething();
}
@Benchmark
public void reflection() throws Exception {
method.invoke(obj);
}
}
分层拆解：测清楚每一处损耗来源
不要只测“反射 vs 直接调用”一个数字。要拆开测，才能知道瓶颈在哪、优化往哪使劲：
立即学习“Java免费学习笔记（深入）”；
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- Method查找开销：每次调用都getMethod() vs 缓存Method对象后调用
- 访问检查开销：调用前是否setAccessible(true)（关闭安全检查）
- 参数装箱开销：用基本类型参数（如int）vs 包装类（Integer），观察invoke()前后自动装拆箱影响
- JIT友好度：运行足够长时间（如JMH跑10轮×每轮1秒），看反射调用是否会随时间被部分优化（通常不会内联，但可能有小幅提升）
关键对照组必须包含
一份合格的测试至少要有这4组对比，缺一不可：
- ✅ 直接方法调用（baseline，1x）
- ✅ 反射调用 + 缓存Method + setAccessible(true)（优化后反射）
- ✅ 反射调用 + 每次重新getMethod()（最差实践）
- ✅ 反射调用 + 缓存Method但未setAccessible（保留安全检查）
这样就能量化出：
— 缓存Method能提速多少倍？
— 关闭检查又能再省多少？
— 不缓存的代价到底多高？
注意真实场景建模
别只测getter/setter这种简单方法。应覆盖典型高频场景：
- 带2~3个参数的方法（尤其含基本类型，触发装箱）
- private方法调用（强制需要setAccessible）
- 泛型方法（验证桥接方法是否影响索引匹配）
- 配合ReflectASM等第三方库做横向对比（如MethodAccess.getIndex + invoke）
例如测JSON反序列化中字段赋值：用反射setter vs ReflectASM vs 直接编译生成的setter代理——这才是工程落地的真实参照系。
