运行时获取注解性能极差，单次耗时100–350纳秒，比普通方法调用慢一个数量级，主因是JVM需执行完整反射流程且无法充分JIT内联；应优先用APT编译期生成代码替代，或分层缓存Method对象、慎用RUNTIME注解。
运行时获取注解确实有明显性能开销，不是“有点慢”，而是比直接调用高一个数量级——实测中单次 method.getAnnotation() 耗时常达 100–350 纳秒，而普通方法调用仅需几纳秒。这种差距在高频场景（如 Web 请求拦截、AOP 日志、DTO 转换）下会迅速放大，成为瓶颈。
为什么运行时读注解这么慢
每次反射读取都触发完整 JVM 运行时流程：定位类结构 → 解析字节码中的注解表 → 检查访问权限 → 实例化注解代理对象 → 处理默认值逻辑 → 经过 JNI 边界跳转。这个过程无法被 JIT 充分内联，且受安全检查、GC 压力和缓存失效策略影响，波动大、冷启动延迟高。
更关键的是：RUNTIME 注解本身就会增大 class 文件体积、拖慢类加载，并在堆中长期驻留元数据，增加 GC 负担。如果只是用来做配置或绑定，却选了 RUNTIME，等于主动引入可避免的开销。
缓存优化的核心原则
不是“加个 ConcurrentHashMap 就完事”，而是分层控制、按需缓存、避免误用：
-
只缓存 Method/Field/Class 对象，不缓存 getAnnotation() 结果：因为
getAnnotation()返回的是动态代理实例，每次调用都新建；而Method对象是稳定的，复用它才能真正省掉查找开销 - 用静态 final 缓存高频反射入口：比如在工具类 static 块中预加载常用 Method，避免每次 new 或重复查找
- 按业务粒度缓存，而非全局暴力缓存：例如一个 Controller 类的所有 @RequestMapping 方法，可在类初始化时批量扫描并缓存到本地 Map，而不是等每次请求再单个反射
- 配合 ClassValue（Java 8+）实现无锁、GC 友好的类级缓存：它能自动随 Class 卸载而清理，避免内存泄漏风险
更优解：优先用编译时注解处理器替代
如果目标是“根据注解生成行为逻辑”，比如字段校验、对象映射、事件绑定——根本不需要运行时反射。用 @Retention(RetentionPolicy.SOURCE) 配合 APT（如 AutoService + JavaPoet），在编译期生成标准 Java 代码：
- 生成的类参与正常编译，调用就是普通方法，JVM 可完全内联优化
- 零运行时元数据、零反射开销、零启动延迟
- 类型错误、空指针等在编译期暴露，不等到上线才崩
- 混淆后仍可用——生成的代码天然适配重命名后的类名和方法名
像 MapStruct、Lombok、JetBrains 的 @NotNull 处理，都是这一思路的成熟实践。百万次映射场景下，APT 方案耗时稳定在 8–12 ns，而反射方案即使加缓存也难低于 80 ns，且稳定性差。
实在绕不开反射时的实用技巧
若必须用 RUNTIME 注解（如兼容 Spring 生态、动态插件机制），建议：
- 用
MethodHandle替代Method.invoke()：性能接近直接调用，JIT 友好 - 避免
setAccessible(true)频繁调用：它会触发 SecurityManager 检查（即使未启用策略），应提前设好并复用 - 对注解属性访问做懒加载：比如只在真正需要
annotation.value()时才调用，而非一上来就全量解析 - 用 GraalVM Native Image 时特别注意：反射需显式注册，否则运行时报错；而 APT 生成的代码天然支持原生编译
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
