直接缓存注解对象是最有效、最易落地的优化手段，因其避免了每次getAnnotation()时动态生成代理、重复解析和安全检查等开销；应以Method或Field为key用ConcurrentHashMap懒加载缓存，慎用全局Class级缓存以防ClassLoader泄漏。
运行时反射读取注解会显著拖慢 JVM 执行效率，核心问题不在“能不能用”，而在于“反复创建代理、重复解析、每次调用都走完整安全链路”。直接缓存注解对象是最有效、最易落地的优化手段。
为什么每次 getAnnotation() 都很贵
Java 的注解在运行时不是普通对象，而是 JVM 用 AnnotationInvocationHandler 动态生成的代理实例。每次调用 method.getAnnotation(MyAnn.class)，JVM 都要：
- 确认类已加载、注解存在于常量池
- 动态生成并初始化代理类
- 构造
memberValues（一个 HashMap）填充默认值和显式值 - 执行访问控制检查（即使没开 SecurityManager，也走检查流程）
这些操作单次耗时在百纳秒级，但高频场景（如 Web 请求拦截、JSON 序列化遍历字段）下，累积开销会立刻显现——尤其当每秒调用数千次时，CPU 时间明显被吃掉。
ConcurrentHashMap 缓存注解对象的正确姿势
注解本身不可变，只要缓存的是同一 Method 或 Field 实例上的注解，复用完全安全。关键在于缓存粒度和 key 设计：
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
立即学习“Java免费学习笔记（深入）”；
- 用
Method或Field对象作 key（它们重写了equals/hashCode），不要拼字符串（如"com.X#m"），避免哈希冲突和 ClassLoader 泄漏风险 - 用
computeIfAbsent()实现懒加载：首次访问才反射解析，后续直接返回缓存结果 - 避免全局缓存 Class 级注解——类对象生命周期长，容易导致 ClassLoader 无法卸载；按业务模块隔离或配合弱引用更稳妥
示例：
private static final Map<Method, ApiEndpoint> ENDPOINT_CACHE = new ConcurrentHashMap<>();ApiEndpoint getEndpoint(Method m) {
return ENDPOINT_CACHE.computeIfAbsent(m, method -> method.getAnnotation(ApiEndpoint.class));
}
再进一步：MethodHandle 加速属性访问
就算缓存了注解对象，调用 ann.value() 仍是接口方法调用，背后还是 InvocationHandler.invoke() 分发。对超高频场景（比如每毫秒数百次读取），可预热 MethodHandle：
- 在首次获取注解时，用
MethodHandles.lookup().unreflect(method)获取属性 getter 的句柄 - 把句柄存入静态 map（key 可为
Method+ 属性名），后续直接handle.invoke(ann) - 实测耗时能从 120ns 压到约 60ns，且线程安全，无需额外同步
别踩这些坑
缓存看似简单，但几个细节处理不好反而引入新问题：
- 热部署环境下（如 Spring DevTools），旧 Class 的 Method 对象仍被缓存引用，导致 ClassLoader 泄漏——需监听类重载事件主动清空对应缓存
- 泛型丰富或嵌套注解（如
@Nested）不用单独缓存内部注解，顶层注解实例已包含全部元数据，嵌套属性访问仍走代理，不影响缓存有效性 - 不要缓存
Class.forName()结果——JVM 内部已做强缓存，重复调用几乎无开销
