减少反射与动态代理开销的关键是将运行时元数据解析、字节码生成和安全检查前移至编译期或启动初期，通过缓存反射元素、优先JDK代理、精确切点、AOT固化、注解处理器生成代码等方式“用得更聪明”。
减少反射与动态代理开销，本质是降低运行时元数据解析、字节码生成和安全检查带来的延迟与GC压力。Spring、MyBatis 等主流框架大量依赖反射和动态代理（如 JDK Proxy 或 CGLIB），但这些操作在启动阶段集中触发，会显著拖慢初始化速度；在运行时高频调用，则影响吞吐和响应延迟。优化不是“不用反射”，而是“用得更聪明”。
精简反射调用链，避免重复解析
反射性能瓶颈常来自反复调用 Class.getMethod()、Field.get() 等——每次调用都需查找、校验、缓存未命中。关键策略是：缓存已解析的反射元素，并复用。
- 对高频访问的字段/方法，使用
MethodHandle替代Method.invoke()：它绕过 AccessControl 和参数包装，性能接近直接调用（JDK 7+） - 用
ConcurrentHashMap缓存Method或Constructor实例，键为类+方法签名，避免每次重新查找 - 避免在循环或高频路径中调用
getDeclaredMethods()等批量获取 API；改为启动时预扫描并构建索引结构
限制动态代理生成时机与范围
Spring AOP 默认对每个 Bean 创建代理对象，CGLIB 动态生成子类字节码，带来类加载、验证、JIT 编译等开销。尤其在 Bean 数量多、切面泛滥时，启动耗时陡增。
- 启用
@EnableAspectJAutoProxy(proxyTargetClass = false)优先使用 JDK 接口代理（比 CGLIB 轻量，不生成新类） - 通过
@Aspect的pointcut精确限定目标类和方法，避免全包扫描式匹配（如不用execution(* com.example..*.*(..))这种宽泛表达式） - 对无状态、无事务、无日志需求的 Bean，显式排除代理：
@Scope(proxyMode = ScopedProxyMode.NO)或使用@Primary+ 手动注入替代自动代理
利用 AOT 编译提前固化反射元数据
GraalVM Native Image 支持在构建期静态分析反射使用点，并将 Class.forName、Method.invoke 等调用提前绑定，彻底消除运行时反射开销。但前提是显式声明反射配置。
- 在
reflect-config.json中只注册真实需要反射的类、方法、字段（Spring Boot 3.2+ 可配合spring-aot自动生成） - 禁用运行时动态类加载：移除
Class.forName("xxx")字符串拼接逻辑，改用编译期可推导的类型引用 - 避免框架扩展点滥用反射——例如自定义 Starter 中不要用
ServiceLoader.load()加载未知实现类，改用 Spring 的@ConditionalOnClass声明式注册
用注解处理器替代运行时反射
很多原本靠运行时反射读取注解的场景（如 Lombok 的 @Data、MapStruct 的映射逻辑），可通过编译期注解处理器（APT）生成代码，完全规避反射。
- 自定义业务注解时，优先设计 APT：在
javac阶段生成XXXMapperImpl或XXXBuilder类，运行时直接 new 调用 - Spring Boot 3 引入的
@Generate...Bean系列（如@GenerateBeanDefinition）即为此类思路，将 Bean 定义生成提前到编译期 - 配合
record和sealed类型，让编译器推导更多结构信息，减少运行时 introspection 需求
不复杂但容易忽略：真正拖慢框架的，往往不是单次反射调用，而是成千上万个 Bean 在启动时各自做一遍字段扫描、方法匹配、代理创建。把“运行时决定”尽可能前移到编译期或启动初期一次性完成，才是降本增效的关键路径。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
