我面试Java开发的时候特别喜欢问一个问题“把Override去掉你的代码还能正常跑吗”大部分候选人会愣一下然后说“能吧”。确实能但这个问题真正的考点是——你对注解的理解到底停留在“给代码做个标记”还是透彻到了“注解是带生命周期的元数据它必须有处理器去读它才有意义”。这一篇是“新Java基础”系列的第十八篇我们来把Java注解这件事彻底聊透。你会发现它没那么神秘但也绝不是IDE里灰色的小标签那么简单。无论你是在准备面试、复习基础还是想把自定义注解用到实际项目里这篇都应该能帮上忙。我会从注解的本质讲起再过一遍JDK内置注解和元注解最后用一块完整代码演示自定义注解从定义到反射解析的闭环再结合Spring里常见注解把实战部分补上。1. 注解不是“注释”先搞懂它到底是个什么东西1.1 注解的本质是元数据先纠正一个最常见误解注解Annotation和注释Comment虽然中文只差一个字但完全是两种东西。注释是给人看的编译器直接忽略注解却是给程序看的结构化信息它会被编译器、JVM或者某个框架读取然后触发对应的处理逻辑。用大白话说注解就是贴在代码上的“便利贴”。便利贴本身不做事但看到便利贴的人会做事。比如你贴一张写有“这里下班前必须检查”的便利贴你的同事看到后会真的去检查注解也一样它只是一段带格式的数据真正干活的是读取这段数据的处理器。Java官方的定义更学术一点注解是接口的一种特殊形式它实现了Metadata元数据机制。元数据就是“描述数据的数据”。打个比方一本书的内容是数据而书的封面、标题、作者、定价就是这本书的元数据。注解之于类、方法、字段就像封面信息之于书的内容——它不改变书的内容但它影响别人怎么对待这本书。值得注意的一个点注解不是Java语言从第一天就有的东西。它是在JDK 5.0时作为新特性引入的目的是减少XML配置的繁琐让配置信息更贴近代码本身。后来的Spring框架把这一理念发挥到了极致所以今天你在Java项目里看到的几乎所有框架都严重依赖注解。1.2 注解的生命周期SOURCE、CLASS、RUNTIME既然注解是数据它就有一个保存多久的问题。Java把注解的保留策略分成了三档对应枚举RetentionPolicy保留策略存储位置典型场景能否反射读取SOURCE仅存在于源码编译时被丢弃Override、SuppressWarnings否CLASS编译时写入字节码但JVM加载时丢弃部分字节码工具、第三方库否默认策略RUNTIME一直保留到JVM运行时Spring相关注解、Transactional是可通过反射读取这个表格建议刻在脑子里因为面试问“注解和反射怎么配合”时答案的第一句话一定是要能被反射读到的注解Retention必须是RUNTIME。而JDK内置的Override是SOURCE所以你反编译class文件时根本看不到它。举个例子你可以用javap命令反编译一个带Override的类javap -v YourClass.class你会看到class文件里并没有Override对应的RuntimeVisibleAnnotations因为它压根就不会被写进字节码。而Spring的Component这样的运行时注解则会出现在RuntimeVisibleAnnotations属性里。1.3 注解本身没有魔法处理器才有很多初学者会有一种错觉注解好像有魔法标一下Component类就变成Bean了标一下Transactional方法就有事务了。其实注解本身什么都没有做它只是一块静态数据。真正让功能生效的是那些扫描注解的处理器代码。这些处理器分两类。第一类是编译期处理器比如Lombok的注解处理器它在javac编译阶段读取源码里的注解直接改写了抽象语法树在字节码里帮你生成getter、setter、构造器。第二类是运行期处理器比如Spring容器启动时会扫描classpath下所有带有Component的类通过反射读取注解然后把对应的Class注册成BeanDefinition再实例化成Bean放到容器里。理解了这一点你再看任何注解都不会再觉得神秘它背后一定有一个“读注解的人”。如果你自己写了一个注解但没有任何代码去读它那它就只是代码里的一行装饰毫无作用。这个认知是学自定义注解之前必须先建立的。2. 内置注解和元注解先用明白官方提供的工具2.1 四个高频内置注解JDK在java.lang包里内置了几个注解它们用法简单但在面试题里出现频率极高。Override标记一个方法是重写父类或接口的方法。它是SOURCE级别注解作用是编译期校验——如果你方法签名写错了比如参数类型对不上、方法名拼错编译器会直接报错而不是让你在运行时才发现调错了方法。去掉它代码照样能跑但等于放弃了一个免费的编译期检查。Deprecated标记某个类、方法、字段已经过时不建议继续使用。它有两个可选属性Java 9之后才有since表示从哪个版本开始废弃的forRemoval表示是不是计划在未来的版本中彻底移除。如果forRemoval为trueIDE通常会给出更醒目的警示。SuppressWarnings抑制编译器警告。常见取值包括all抑制所有警告、unchecked泛型相关的未检查警告、serial序列化相关警告、deprecation使用废弃API的警告。注意这玩意是治标不治本你可以抑制警告但代码本身有没有问题要自己想清楚别为了消除IDE的红线把真正的问题也藏了。FunctionalInterfaceJava 8引入用来标记函数式接口。加了它之后编译器会强制检查这个接口只能有一个抽象方法如果方法数量不对直接编译失败。这个注解本身不影响运行但它能保证你的接口符合lambda表达式的要求。2.2 元注解用来注解的注解元注解就是标注在注解上的注解它决定了你自定义注解的行为。一共五个再加Java 8的Repeatable我把它们逐一拆开讲。Retention上面已经讲过它决定注解的生命周期取值只能是SOURCE、CLASS、RUNTIME三者之一。如果你希望自己定义的注解能在运行期被反射读取就写成Retention(RetentionPolicy.RUNTIME)。Target决定注解能放在哪些位置取值来自ElementType枚举。我用一张表整理一下最常用的几个ElementType说明常见用途TYPE类、接口、枚举类级别注解如ComponentFIELD字段Autowired、ValueMETHOD方法Transactional、OverridePARAMETER方法参数RequestParam、PathVariableCONSTRUCTOR构造器少见ANNOTATION_TYPE注解类型上元注解LOCAL_VARIABLE局部变量极少用TYPE_USE任何类型引用处类型注解如泛型如果一个注解不写Target它可以被放在任何位置但这通常不是你想要的行为。自定义注解时最好显式声明目标位置否则后续维护时很容易出现注解贴错地方的尴尬。Documented表示这个注解要出现在javadoc文档里。不加的话即便你的类用javadoc生成文档注解信息也不会被记录。Inherited表示注解可以被子类继承。但这里有个巨大的坑——它只对“类上的注解”生效对接口上的注解、方法上的注解都不生效。父类标了Inherited注解子类继承父类时算是有但父类方法上的注解子类重写这个方法后并不会继承。我后面会专门用一节讲这个限制。RepeatableJava 8加入允许同一个位置重复标注同一个注解多次。它的底层实现是用一个“容器注解”来装多个注解。例如Schedules就是Schedule的容器Repeatable(Schedules.class) public interface Schedule { String dayOfMonth() default first; } Schedules({ Schedule(dayOfMonth last), Schedule(dayOfMonth friday) }) public void scheduledTask() {}JDK自带的Schedules就是这么一个容器注解内部的value属性是一个Schedule数组。2.3 注解的定义里方法就是属性这一节算给后面自定义注解做预热。注解里写的东西形式上很像方法但语义上是属性。比如public interface MyAnno { String value(); int count() default 0; }这里的value()和count()就是注解的两个属性。使用的时候写成MyAnno(value abc, count 1)。如果一个注解只有一个属性且名字叫value那么使用的时候可以省略属性名直接写MyAnno(abc)。属性类型有限制这一点极其重要只能是Java的8种基本类型byte、short、int、long、float、double、char、boolean、String、Class、枚举类型、注解类型以及这些类型的数组。不能是Integer这种包装类型不能是Object不能是泛型也不能是任意自定义的类。原因是注解的属性值必须在编译期就确定下来它最终要写进class文件运行时对象是无法静态表示的。3. 自定义注解的完整套路从指尖定义到反射解析3.1 一个能落地的方法耗时统计注解理论讲完了接下来给一套可以直接复制到项目里跑的完整代码。我们的目标很朴素写一个CostTime注解标在某个方法上程序运行的时候自动打印这个方法消耗了多少毫秒。第一步定义注解。这里我用RUNTIME策略和METHOD目标import java.lang.annotation.ElementType; import java.lang.annotation.Retention; import java.lang.annotation.RetentionPolicy; import java.lang.annotation.Target; Retention(RetentionPolicy.RUNTIME) Target(ElementType.METHOD) public interface CostTime { String unit() default ms; }第二步写一个解析器。解析器要拿到目标Class遍历它的方法找出带CostTime的方法然后通过反射调用并记录时间。这里我故意都放在一个类里方便演示import java.lang.reflect.Method; public class CostTimeDemo { CostTime(unit ms) public void slowMethod() throws InterruptedException { Thread.sleep(500); } public static void main(String[] args) throws Exception { CostTimeDemo demo new CostTimeDemo(); // 获取类的所有方法 Method[] methods CostTimeDemo.class.getDeclaredMethods(); for (Method method : methods) { // 判断方法上是否标注了 CostTime if (method.isAnnotationPresent(CostTime.class)) { CostTime annotation method.getAnnotation(CostTime.class); String unit annotation.unit(); long start System.nanoTime(); method.invoke(demo); // 反射调用 long cost (System.nanoTime() - start) / 1_000_000; System.out.println(method.getName() 耗时 cost unit); } } } }跑一下main方法控制台会输出类似slowMethod 耗时500ms的结果。这个例子的精髓在于CostTime注解本身什么都没做是我的解析器通过isAnnotationPresent判断“方法上有没有贴这个标签”有就执行计时逻辑。你完全可以把这段代码扩展成一个通用的工具类扫描整个包的所有类然后把耗时统计统一加上不用改业务代码。3.2 反射解析的API四板斧上面的例子已经用到三个核心API。我再把它们梳理一遍顺便补一个容易忽略的。isAnnotationPresent(Class)判断某个元素上是否存在指定注解返回boolean。这是最常用的判断方法。getAnnotation(Class)获取指定类型的注解实例不存在则返回null。拿到实例之后就可以读注解的属性值了。getAnnotations()返回该元素上所有注解数组包括继承下来的注解。getDeclaredAnnotations()返回该元素上直接声明的所有注解不包括继承的。这个API是很多初学者踩坑的地方——当你以为“我父类有注解子类也应该有”时其实子类通过getAnnotations()能看到但getDeclaredAnnotations()看不到。这四个方法都来自java.lang.reflect.AnnotatedElement接口Class、Method、Field、Constructor、Parameter都实现了这个接口所以你能对类、方法、字段、构造器、参数分别做注解解析。3.3 不只是反射还有编译期注解处理很多时候我们并不想在运行期通过反射读注解因为反射有性能开销而且有些信息在运行期已经没有意义了。这时候可以用编译期注解处理器也就是Java自带的APTAnnotation Processing Tool。Lombok就是编译期处理器的典型代表。你在源码里写一个DataLombok的注解处理器在javac编译阶段读取这个注解直接修改抽象语法树在生成的字节码里加上getter、setter、equals、hashCode等方法。所以运行期你根本不需要反射方法就在那里速度自然没有损耗。自己写编译期处理器需要继承javax.annotation.processing.AbstractProcessor重写process方法再通过META-INF/services注册。这套东西的完整开发流程比较长这篇先不展开你只要记住两个方向运行期反射读注解适合框架型功能如Spring编译期生成代码适合工具型功能如Lombok。根据场景选路别一上来就反射。4. 注解在Spring的世界里是怎么“活”起来的4.1 从Component到Autowired容器是怎么读注解的Spring大概是注解使用最密集的Java框架拿它来讲实战最合适。Spring容器启动时有一个核心组件叫ClassPathBeanDefinitionScanner类路径Bean定义扫描器。它会扫描指定包下所有的class文件查找那些标注了Component等注解的类然后把扫描到的类注册成BeanDefinition。这里的读取逻辑用一个词概括就是“反射读取注解”。看到Component就把这个类当成一个Bean候选看到Repository、Service、Controller这些本质上都是Component的“派生注解”只是语义上区分了层次。再看Autowired。它是由AutowiredAnnotationBeanPostProcessor这个后置处理器处理的。Spring创建Bean的时候会遍历每个Bean的字段、方法、构造器找到标了Autowired的地方然后通过类型或名称在容器里找到对应的依赖并注入进去。这里有一个面试常问的细节Autowired和Resource到底有什么区别Autowired是Spring的注解按类型注入如果需要按名称注入要配合QualifierResource是JSR-250标准注解按名称注入找不到名称再按类型。实际项目中用哪个看团队规范但面试时你要能说清这个区别。4.2 Transactional事务注解为什么总容易失效Transactional是Spring里被问爆的话题因为失效场景实在太多了。原理其实一句话就能说明白Spring的事务是通过AOP动态代理实现的只有“调用经过代理对象”时事务增强逻辑才会生效。方向对了失效原因就很好记了。最经典的失效场景是同类内部调用。你写了一个方法A方法内部调用了另一个带Transactional的方法B但这里的this.methodB()走的是原始对象不是代理对象事务注解根本没被处理器看到。解决方法有三种注入自身代理、拆分到另一个Service、通过AopContext.currentProxy()获取代理再调用。第二个高频场景是private方法上标Transactional。JDK动态代理只能增强接口方法CGLIB虽然能代理类但private方法不会被生成增强逻辑所以同样失效。Spring官方建议事务注解加在public方法上这不是风格问题是实现机制决定的。第三个场景是异常被吞。事务回滚的触发条件是RuntimeException或Error如果你在方法里catch住了异常不往外抛Spring根本感知不到异常事务就会正常提交。要让它回滚要么不catch要么在catch后抛出要么用rollbackFor指定异常类型。4.3 RequestBody到底能不能加两个参数这个问题的答案网络上吵得很凶结论是这样的同一个方法里不能写两个RequestBody因为一个请求体只能被解析绑定一次。如果你写了两个Spring会直接报错。如果你需要接收一组复杂参数正确的做法有两个一是包装成一个DTO对象二是用RequestBody MapString, Object接收整个JSON再自己取字段。不过注意一个方法里可以同时用RequestBody和RequestParam。为什么能共存因为一个是绑定请求体一个是绑定URL查询参数或表单参数两者解析来源不同Spring可以分别处理。我在实际项目里经常这么用比如接口路径上带一个version参数请求体里是完整的业务对象数据。面试时如果被问到你可以把“RequestBody只能绑定一个对象”作为第一句话然后立刻补上“但可以配合RequestParam或者包装DTO来扩展”这个回答就完整了。4.4 Value和SpEL表达式注解里还能写字面量之外的东西Value是用来注入配置值的注解它有两种常见用法很多新手混在一起分不清。第一种是配置文件占位符Value(${app.name})Spring会从application.properties或application.yml里找app.name这个属性找不到就报错。可以给默认值Value(${app.name:defaultName})冒号后面是兜底值。第二种是SpEL表达式Value(#{systemProperties[user.home]})。这里用的是SpELSpring Expression Language它可以执行表达式、调用静态方法、做运算。比如Value(#{T(java.lang.Math).random()})能直接注入一个随机数。两者的区别就一个大括号${}读配置#{}跑表达式。如果一个值同时用了两层比如Value(#{${maxNum}1})就是先读配置再在SpEL里做运算。这个组合在复杂配置场景很实用。4.5 SneakyThrowsLombok是如何骗过编译器的热词里出现了一个很典型的Lombok注解SneakyThrows。它的作用是让受检异常checked exception可以不用在方法签名里声明throws也不用try-catch直接把代码写得很干净。随手写个例子import lombok.SneakyThrows; public class SneakyThrowsDemo { SneakyThrows public void readFile() { // 这里不需要写 throws IOException java.nio.file.Files.readAllBytes(java.nio.file.Paths.get(d:/test.txt)); } }这是在“骗编译器”而不是“消除异常”。Lombok在编译期做了手脚它把受检异常包装成一个不检查的异常抛出去或者通过泛型擦除的技巧让编译器认为这个方法不会抛受检异常。运行期该抛的异常照样会抛。所以能用但别因此忽视异常处理本身在事务方法里unchecked异常反而更容易触发回滚这算是一个隐藏特性。5. 注解的坑与边界性能、继承、IDE这些绕不过去的点5.1 反射读注解到底慢不慢很多人一听到反射就皱眉觉得性能很差。建议先量化一下JVM对反射做了大量优化单次getAnnotation的耗时通常在微秒或纳秒级别和一次普通的对象创建差不多。在绝大多数业务系统里注解解析发生在Bean初始化阶段每个类只解析一次这个开销完全可以忽略。真正要小心的是把注解解析写进热循环。比如你有一个每秒执行几万次的方法每次都在循环里调用getAnnotation那就不仅慢还会给JIT优化添麻烦。解决办法非常朴素把解析结果缓存到Map或常量里只解析一次。Spring内部就是这么干的它会把注解元数据缓存起来避免重复扫描。5.2 Inherited的局限和常见的误解前面提过Inherited只对类生效这里展开讲透。假设你定义了一个注解Inherited Retention(RetentionPolicy.RUNTIME) Target(ElementType.TYPE) public interface ClassInfo { String author() default unknown; } ClassInfo(author 张三) public class Parent {} public class Child extends Parent {}这时候通过Child.class.getAnnotation(ClassInfo.class)是能拿到ClassInfo的因为Inherited让子类继承了父类上的这个注解。但如果你把ClassInfo标在父类的一个方法上子类重写这个方法通过子类方法反射是拿不到这个注解的。接口也一样接口上注解不会透传给实现类。这个坑面试官特别喜欢挖因为他知道很多人会对“继承”两个字过度理解。5.3 注解的属性值必须编译期确定自定义注解的属性值必须是编译期常量。这意味着你不能写MyAnno(value new String(abc))也不能写MyAnno(value someMethod())更不能把运行时计算的结果塞进注解。如果你的业务场景确实需要“动态参数”那注解就不适合了应该换个思路。比如用注册表模式把一个Class映射到一组运行时配置或者用配置文件描述规则又或者把动态数据放在注解的一个枚举标识里由处理器根据枚举值去查表。总之注解的价值是静态、结构化、贴近代码它不适合承载运行时才产生的信息。还有一个细节注解属性不支持null。如果你想让调用者不填某个属性就提供一个合理的default默认值然后由处理器判断“值等于默认值”来决定走不走相关逻辑。别指望注解属性值是null那是编译不过的。5.4 关于IDE和开发效率的两个小提醒热词里有一条很具体的问题IDEA里写注解时输入小写字母不联想注解。我遇到过类似情况这里给几招排查顺序。先检查项目依赖是否完整引入比如Spring的注解需要spring-context在classpath里如果依赖没问题在IDEA里执行一次Rebuild Project因为有时候是索引没更新导致联想失效再检查Settings里的Editor General Code Completion确认没有误关闭匹配选项。如果都不行还有一个土办法直接用全称写一次import导入之后IDEA就会记住这个类联想就恢复了。这个坑多半是IDE索引和输入法切换状态混合导致的问题不是Java注解本身有什么限制。另外一个开发效率提升的点是多用自己的自定义注解把重复逻辑收敛起来。比如我常给团队的RPC接口写一个RouteLog注解用来统一记录入参出参效果是接口方法里一行日志代码都不用写切面或者解析器自动处理。这种“注解处理器”的组合才是注解在工程里的正确打开方式。5.5 注解设计原则什么样的注解是好注解最后给你一份我自己踩过不少坑后总结的检查清单定义自定义注解前先过一遍注解要有明确且单一的职责不要一个注解干五件事属性太多会让人无所适从尽量给每个属性提供默认值减少使用方的负担每个注解都要有对应的处理逻辑没有处理器的注解就是死代码先想好谁来读它再定义它运行时注解别滥用能编译期解决的事不要拖到运行期拆包内聚的原则同样适用和某个模块强相关的注解不要放在公共包里这五条不是理论是实际项目里被证明有效的经验。注解用得好的项目代码读起来就像说明书用不好的项目到处都是不知道从哪来的装饰标签排查问题时反而多一层阻碍。我自己的习惯是把一个项目里所有自定义注解集中放在一个包下比如annotation包同时配套一个解释每个注解用途的README。时间长了你会发现注解不仅是给机器看的更是给后来维护代码的人看的。它把设计意图压缩在代码旁边比任何文档都贴近真相。希望这一篇能帮你把Java注解这一环彻底打通下一步再遇到Spring源码里那些密密麻麻的注解就不再是障碍了。