应缓存field.getannotation结果以避免高频gc：每次调用都会解析字节码、创建动态代理对象并执行安全检查，导致短命对象激增和ygc雪崩；正确做法是按field实例缓存，优先静态预加载，或改用编译期/启动期元数据方案。
因为每次调用 Field.getAnnotation 都会触发反射元数据解析与注解实例化，生成大量短命对象，迅速填满年轻代并引发高频 YGC；在死循环中高频执行时，该行为等同于主动制造 GC 雪崩，严重拖慢吞吐、抬高 P99 延迟，甚至诱发 Full GC。
根本原因：getAnnotation 不是“读取”，而是“构造”
不同于字段值访问，getAnnotation 在运行时并非从缓存中返回已有实例。JVM 每次调用都会：
- 解析注解类的字节码，构建 Annotation 实例（本质是动态代理对象）
- 初始化其所有默认属性（即使未显式设置）
- 执行安全检查（如模块 opens、包可见性校验）
- 在 JDK 9+ 中，若未预配置
addOpens，还会触发模块系统遍历
高频死循环放大危害：对象爆炸 + GC 失控
假设一个每秒处理 10 万条记录的解析线程，每条记录需检查 5 个字段的 @Sensitive 注解：
- 单次循环产生 5 个新 Annotation 实例（每个约 128–256 字节）
- 每秒新增 50 万个短命对象 → 年轻代几毫秒即满 → YGC 频率飙升至每 10–20ms 一次
- YGC 吞吐下降、Stop-The-World 累计时间陡增，接口响应毛刺明显
- 若伴随大对象晋升或内存碎片，可能连锁触发 Full GC
正确做法：必须缓存，且缓存粒度要准
注解本身不可变，但缓存必须绑定到 Field 对象生命周期，而非仅靠字段名或类名：
- 优先使用
static final Field+ 预调用field.getAnnotation(...)，在类加载期完成解析并复用结果 - 对动态类结构，用
ConcurrentHashMap<field annotation></field>缓存，Key 必须是 Field 实例（避免因类加载器隔离或 CGLIB 增强导致误命中） - 禁用
WeakReference<annotation></annotation>：Annotation 是轻量代理，不持业务对象引用，弱引用无意义且增加 GC 开销 - 若需泛化处理（如统一扫描某类注解），改用
Class.getDeclaredFields()一次性获取全部字段后批量提取注解，再缓存结果 Map
更优替代：绕过反射，用编译期/启动期元数据
对性能极端敏感场景，应规避运行时反射：
- 使用
AnnotationProcessor在编译期生成注解索引类（如XXXAnnotationIndex.java），直接硬编码映射关系 - Spring Boot 3+ 可结合
@ConfigurationProperties和Validated的静态验证树，跳过字段级注解反射 - 自研框架可借助
LambdaMetafactory或MethodHandle构建注解元数据访问句柄，首次解析后长期复用
