Java运行时注解加载机制：Retention的影响总结

Ja va注解运行时能不能读到，这个问题其实挺有意思的——说到底，核心就一句话：不是注解写了就管用，得看@Retention有没有设对。只有RUNTIME策略的注解，才能在程序跑起来以后通过反射真正拿到手；SOURCE和CLASS这两种，getAnnotation()永远返回null。不是你代码写错了，是注解压根没进JVM内存。

为什么只有 RUNTIME 能被反射读到

道理其实很简单。RUNTIME策略的注解会完整写入.class文件，等类加载的时候，JVM会把它一并加载进元空间（Metaspace），作为类元数据的一部分常住内存。这时候Class、Method、Field这些反射对象才能通过底层机制访问到它。

对比一下就清楚了：

• SOURCE注解：ja vac编译完，直接人间蒸发，.class文件里找不到任何痕迹
• CLASS注解：虽然保留在.class文件中，但JVM不把它加载进运行时内存，反射API自然查不到

换句话说，SOURCE像一张带不走的草稿，CLASS像一本藏在书里的注释纸，只有RUNTIME才是真正印刷在封面上的标签。

RUNTIME 的真实开销不能忽视

不少开发者觉得“加个RUNTIME不就是多写一行配置的事吗？”——还真不是。它带来的运行时负担是实实在在可量化的：

首先，每个RUNTIME注解会让.class文件膨胀几十到上百字节，这还没完，还得多塞常量池项、属性描述符。类加载的时候，JVM需要解析并缓存注解结构，一旦项目规模上到百万级类，元空间压力和GC频率都会明显抬头。

其次，反射调用getAnnotation()比普通字段访问慢10到100倍，这不是危言耸听。Spring启动期的高频扫描就是典型例子，实测下来比CLASS策略慢3到5倍。

再者，还有一层容易被忽略的风险：RUNTIME注解可能意外暴露内部逻辑。比如权限规则、埋点开关这些设计细节，本来只想在开发环境用，结果落到生产环境的字节码里，等于把家底亮给了对手。

什么场景必须用 RUNTIME

话又说回来，RUNTIME不是不能用，关键是用对地方。只有在业务逻辑确实需要在运行时动态决策的时候，才值得启用：

• 框架扫描：Spring的@Component、@Controller——没有RUNTIME，Spring就不知道该扫描哪些类
• 运行时拦截：AOP切面读取@LogExecutionTime或@Transactional，靠的就是运行时反射
• 条件控制：比如@Cacheable(enabled = true)、@RequireRole("ADMIN")，这需要运行时判断开关状态
• 序列化策略：Jackson的@JsonFormat(pattern = "yyyy-MM-dd")，也是在运行时决定日期格式

这些场景，用RUNTIME是合理的、必要的。

别把 RUNTIME 当默认选项

很多开发者一上来就给注解加@Retention(RetentionPolicy.RUNTIME)，图省事。但CLASS策略其实是Ja va的默认保留策略，这不是设计缺陷，恰恰是设计权衡——它静默存在于字节码里，供ASM、Byte Buddy、APT这些工具处理，又不增加运行时的成本。SOURCE则更轻量，适合@Override、@SuppressWarnings这类纯编译期用途。

说到底，选择注解策略和选择数据结构是一个道理：没有银弹。盲目全上RUNTIME，等于主动给项目引入启动延迟、内存膨胀和安全隐患。先想清楚这个注解到底要在哪个阶段发挥作用，再决定给它什么保留策略——这才是正解。