运行时解析注解的性能开销主要来自反射调用重复执行，优化关键在于避免重复解析、减少代理创建、跳过冗余检查；四点核心措施：1. 注解必须设为retentionpolicy.runtime；2. 直接缓存注解对象而非每次getannotation()；3. 复用spring的annotationutils；4. 高频读取属性时预热methodhandle加速getter。
运行时解析注解的性能开销主要来自反射调用本身的重复执行，而不是注解本身。优化的关键不是“少用注解”，而是避免重复解析、减少代理创建、跳过冗余检查。以下四点是落地最直接、效果最显著的优化方向：
注解必须设为 RetentionPolicy.RUNTIME
只有 RUNTIME 级别的注解才能被反射读取。若误设为 CLASS 或 SOURCE，反射调用永远返回 null，看似“没开销”，实则导致功能失效，排查成本远高于性能损耗。
- Spring 的
@Transactional、MyBatis 的@Select、校验框架的@NotNull都强制要求RUNTIME - 所有仅用于编译提示（如
@ApiNote）或字节码增强（如构建期 AOP）的注解，应明确设为SOURCE或CLASS，从源头剔除反射路径
直接缓存注解对象，而非每次调用 getAnnotation()
JVM 每次执行 method.getAnnotation(MyAnn.class) 都会：
- 检查类加载状态和常量池是否存在该注解
- 动态生成
AnnotationInvocationHandler代理类 - 构造
memberValues（HashMap）填充默认值与显式值 - 执行安全检查（即使未启用 SecurityManager，也走空分支）
单次耗时约 100–150 ns，高频场景（如每秒千次请求）下 CPU 明显吃紧。
✅ 正确做法：
- 以
Method或Field对象为 key（它们已重写equals/hashCode），用ConcurrentHashMap缓存注解实例 - 使用
computeIfAbsent()实现懒加载：首次访问才反射解析，后续直接返回 - 示例：
private static final Map<method apiendpoint> ENDPOINT_CACHE = new ConcurrentHashMap(); ApiEndpoint getEndpoint(Method m) { return ENDPOINT_CACHE.computeIfAbsent(m, method -> method.getAnnotation(ApiEndpoint.class)); }</method>⚠️ 避免用字符串拼接（如
"com.X#m"）作 key，易引发哈希冲突，且可能造成 ClassLoader 泄漏。
复用 Spring 的 AnnotationUtils，不重复造轮子
Spring 的 AnnotationUtils.findAnnotation() 和 AnnotatedElementUtils.getMergedAnnotation() 已内置：
- 注解继承合并逻辑（如子类方法继承父类
@Deprecated） - 多级缓存（Class → Method → Annotation 实例）
- 对
@Repeatable注解的自动展开支持
直接调用比手写缓存更健壮，尤其在复杂继承或组合注解场景下。
超高频读取属性时，预热 MethodHandle 加速 getter
即使缓存了注解对象，调用 ann.value() 仍是接口方法调用，背后仍经 InvocationHandler.invoke() 分发，耗时约 120 ns。
✅ 进一步优化：
- 在首次解析注解时，用
MethodHandles.lookup().unreflect(method)获取属性 getter 的MethodHandle - 将
MethodHandle存入静态 map（key 可为Method + 属性名） - 后续直接
handle.invoke(ann)，实测压至约 60 ns，线程安全且无同步开销
不复杂但容易忽略。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
