反射调用比直接调用慢的根本原因是绕过编译期优化，被迫在运行时重复执行方法查找、权限检查、参数装箱拆箱及JNI切换，且无法被JIT内联。
Java 反射机制的性能开销，本质是用“运行时灵活性”换来的代价。它绕过了编译期的类型检查、静态绑定和 JIT 优化路径，所有操作都推迟到运行时动态解析和校验，导致每一步都多出若干不可忽略的环节。
反射调用比直接调用慢的根本原因
不是“反射本身慢”，而是 JVM 在执行反射操作时必须补上编译期省略的全部安全与查找逻辑：
- 方法查找开销：getMethod() 或 getDeclaredMethod() 需遍历类及其父类的方法表，匹配名称和参数类型，时间复杂度接近 O(n)
- 每次 invoke 都做权限检查：即使已调用过 setAccessible(true)，JVM 仍需在 invoke 时验证调用上下文是否有足够权限（尤其在安全管理器启用时）
- 无法被 JIT 内联或逃逸分析：invoke 是一个通用的 JNI 调用入口，JIT 编译器无法预测目标方法，自然无法做方法内联、锁消除等关键优化
- 装箱/拆箱与类型擦除补偿：反射 API 统一使用 Object 传参和返回，基本类型必须包装；泛型信息在运行时已擦除，需额外逻辑还原类型语义
三类典型操作的耗时对比（JDK17，纳秒级）
基准测试数据明确揭示了瓶颈分布：
| 操作 | 直接调用 | 反射调用（缓存 Method） | 反射调用（未缓存 Method） |
|---|---|---|---|
| 方法调用 | 2.3 ns | 35.8 ns（≈15.6×） | 145.2 ns（≈63×） |
| 字段读取 | 3 ns | ~280 ns | 更高（含 getField 查找） |
| Class 加载 | — | 类名.class：2.3 ns | Class.forName("x.y.Z")：1250.7 ns |
可见，最重的开销来自 Class 加载和 Method 查找，而非 invoke 本身。频繁 new Class 对象或反复调用 getMethod，会把性能拖入谷底。
deep-java-review
下载
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
立即学习“Java免费学习笔记（深入）”；
哪些场景最容易踩中反射性能坑
不是“用了反射就慢”，而是某些使用模式会放大开销：
- 循环体内反复获取 Method/Field：比如在 for 循环中每次调用 clazz.getMethod("xxx")，而不是提前缓存
- 高频短生命周期对象 + 反射赋值：如 JSON 反序列化中为每个字段新建 Field 实例并 setAccessible
- 未关闭调试/安全策略：开发环境开启 SecurityManager 或 debug 模式，会让每次反射调用触发更严格的校验链
- 混合使用泛型注解 + 实时解析：每次读 @ApiEndpoint.path() 都走一遍 Annotation 解析流程，不缓存结果
性能瓶颈不在“能不能用”，而在“怎么组织调用链”
反射的慢，90% 来自重复解析和未复用元数据。真正的优化不靠黑科技，而靠两点：
- 缓存 Class、Method、Field 引用：首次获取后存入 ConcurrentHashMap 或静态 final 字段，避免重复查找
- 用 MethodHandle 替代 Method.invoke（JDK7+）：MethodHandle 更轻量，支持更激进的 JIT 优化，实测 invoke 开销可降至原反射的 1/3～1/2
- 对私有成员，setAccessible(true) 要在获取后立即调用：它只影响后续 invoke 行为，不加这句等于白缓存
