反射调用比直接调用慢10–100倍，因JVM无法内联Method.invoke()，需动态解析、权限检查、类型匹配、装箱拆箱及异常包装；应缓存Method、设setAccessible(true)，优先用代码生成替代。
反射调用比直接调用慢多少
不是“慢一点”，而是可能慢 10–100 倍，尤其在频繁调用场景下。根本原因在于 JVM 无法对 Method.invoke() 做内联优化，每次调用都要走完整的动态解析流程：检查访问权限、参数类型匹配、装箱/拆箱、异常包装（把受检异常转成 InvocationTargetException），还要绕过 JIT 的热点代码编译路径。
实操建议：
- 避免在循环体内反复调用
clazz.getMethod("xxx").invoke(obj, args)—— 每次都重新查找方法，开销极大 - 如果必须反射调用，提前缓存
Method对象，并设为setAccessible(true)跳过访问检查（注意 JDK 9+ 模块系统限制） - 对性能敏感路径（如序列化框架、RPC 参数绑定），优先用代码生成（如 ByteBuddy）或预编译代理替代运行时反射
JDK 9+ 模块系统让反射更重了
从 JDK 9 开始，setAccessible(true) 不再无条件生效。若目标类在模块中未显式导出（exports）或开放（opens）对应包，会抛 InaccessibleObjectException。JVM 还会记录警告日志，甚至在某些安全策略下直接拒绝。
常见错误现象：
立即学习“Java免费学习笔记（深入）”；
java.lang.reflect.InaccessibleObjectException: Unable to make field private java.util.ArrayList.elementData accessible
解决办法：
- 启动参数加
--add-opens java.base/java.util=ALL-UNNAMED（开发阶段临时绕过） - 生产环境应推动依赖库升级，使用模块声明的
opens或改用标准 SPI 接口 - 不要依赖
sun.*或jdk.internal.*包——它们本就不属于公共 API，JDK 版本一变就崩
Class.forName() 和 ClassLoader.loadClass() 的区别不只是加载时机
Class.forName("X") 默认会触发类初始化（执行 static 块），而 ClassLoader.loadClass("X") 只加载不初始化。很多人误以为只是“是否执行静态代码块”的差异，其实还影响性能和线程安全。
关键影响：
- 类初始化是同步过程，高并发下
Class.forName()可能成为瓶颈（尤其是 Spring 启动时批量加载配置类） - 若类初始化过程中有耗时操作（如读配置、连数据库），用错方式会导致启动卡顿或死锁
- 某些框架（如 Hibernate）内部用
loadClass避免过早触发实体类初始化，你写的反射工具也该留意这点
反射获取泛型类型信息几乎零成本？别信
Field.getGenericType() 或 Method.getGenericReturnType() 看似只是取个对象，但背后要解析字节码里的 Signature 属性，还要构造 ParameterizedType 等接口实现。这不是简单字段访问，而是运行时泛型擦除后的逆向还原。
容易踩的坑：
- 原始类型（如
List）返回Class，带泛型（如List）才返回ParameterizedType—— 忘记 instanceof 判断直接强转会ClassCastException - 嵌套泛型（如
Map）需要递归处理，不少工具类在这里栈溢出或解析错位> - Android 上 Dalvik/ART 对泛型签名支持不一致，同一段反射代码在不同版本可能返回 null
真正影响性能的从来不是“用了反射”，而是没想清楚哪一层该交由反射承担、哪一层该用编译期确定的契约。比如用反射遍历所有 getter 再拼 JSON，不如让对象实现 JsonSerializable 接口并由 IDE 自动生成实现——后者零反射、零运行时开销、类型安全、IDE 可跳转。
