Ryu

large picture of the cover

深入 Spring Boot 注解：一次触及源码的深度旅行

深入 Spring Boot 注解：一次触及源码的深度旅行

我们每天都在使用的 @Autowired、@Service、@RestController，它们看似简单，但背后是一套设计精巧、高度可扩展的机制。要理解这套机制，我们不能只停留在“它是什么”的层面，而要深入“它是如何工作”的源码层面。

这次，我们不谈概念，只看“机器”如何运转。

一、地基：注解处理的核心引擎

Spring Boot 的注解之所以能工作，完全依赖于 Spring 框架在 IoC 容器启动和 Bean生命周期中所提供的一系列“钩子”或“扩展点”。其中最核心、最关键的两个就是 BeanFactoryPostProcessor 和 BeanPostProcessor。

BeanFactoryPostProcessor (工厂后处理器):

  • 触发时机: 在所有 Bean 的定义（BeanDefinition）被加载到 BeanFactory 中之后，但在任何 Bean 实例被创建之前。

  • 作用: 它允许我们修改 Bean 的定义信息。比如，改变某个 Bean 的作用域，或者，更重要的是，扫描并注册更多的 Bean 定义。@ComponentScan 和 @Configuration 的解析就发生在这个阶段。

  • 关键实现: ConfigurationClassPostProcessor。

BeanPostProcessor (Bean 后处理器):

  • 触发时机: 在 Bean 实例化之后，初始化（属性填充、init-method 调用等）的前后。

  • 作用: 它允许我们对已实例化的 Bean进行加工处理。比如，注入依赖（@Autowired），或者为 Bean 生成一个动态代理对象（AOP）。

  • 关键实现: AutowiredAnnotationBeanPostProcessor、CommonAnnotationBeanPostProcessor。

记住这两个处理器，它们是理解后续所有注解原理的钥匙。

二、从启动到就绪：@SpringBootApplication 的幕后

当我们运行主类时，SpringApplication.run() 方法会创建一个 ApplicationContext (应用上下文/IoC 容器)。在这个过程中，核心的注解解析开始了。

@SpringBootApplication 本身我们已经知道是三个注解的集合，但这次我们看它的核心 @EnableAutoConfiguration 和 @ComponentScan 是如何被处理的。

@ComponentScan 的源码之旅

  1. 处理入口: ConfigurationClassPostProcessor (一个 BeanFactoryPostProcessor) 被触发。它的核心任务就是寻找并解析被 @Configuration 注解的类（@SpringBootApplication 已包含）。

  2. 解析过程: 在 ConfigurationClassPostProcessor 的 processConfigBeanDefinitions 方法中，它会创建一个 ConfigurationClassParser (配置类解析器)。

  3. 扫描执行: ConfigurationClassParser 会解析 @ComponentScan 注解。它会创建一个 ClassPathBeanDefinitionScanner。这个扫描器根据 @ComponentScan 定义的 basePackages 路径，开始扫描文件系统。

  4. 过滤与识别: ClassPathBeanDefinitionScanner 的 doScan 方法是核心。它会遍历所有 .class 文件，并使用 AnnotationTypeFilter 来判断一个类是否带有 @Component 注解（或其派生注解，如 @Service, @Repository）。

  5. 注册定义: 对于每个找到的组件，扫描器会为其创建一个 ScannedGenericBeanDefinition (Bean 的“蓝图”或“图纸”)，并调用 BeanDefinitionRegistry 的 registerBeanDefinition 方法，将其注册到 BeanFactory 中。

小结: @ComponentScan 的工作发生在 Bean 实例化之前，由 ConfigurationClassPostProcessor 驱动，其本质是扫描文件系统，找到符合条件的类，并为它们生成定义信息（BeanDefinition），然后存入工厂。此时，还没有任何业务 Bean 的实例被创建。

@EnableAutoConfiguration 的源码之旅

这是 Spring Boot 的精髓，同样由 ConfigurationClassPostProcessor 在同一阶段处理。

  1. @Import 触 发: @EnableAutoConfiguration 上有一个 @Import(AutoConfigurationImportSelector.class)。ConfigurationClassParser 在解析 @Configuration 类时，会处理 @Import 注解。

  2. Selector 的介入: 由于导入的是一个 ImportSelector，解析器会调用 AutoConfigurationImportSelector 的 selectImports 方法，以编程方式决定需要导入哪些配置类。

  3. 加载工厂配置: selectImports 方法的核心是调用 SpringFactoriesLoader.loadFactoryNames(getSpringFactoriesLoaderFactoryClass(), getBeanClassLoader())。

    • 这个静态方法会扫描 classpath 下所有 JAR 包中的 META-INF/spring.factories 文件。

    • 它会寻找以 org.springframework.boot.autoconfigure.EnableAutoConfiguration 为 key 的所有类名列表。

  4. 条件化过滤: 拿到这个庞大的配置类列表后，并不是全部加载。AutoConfigurationImportSelector 会进行两轮过滤：

    • 排除过滤: 根据 @EnableAutoConfiguration(exclude=...}) 进行排除。

    • 条件评估: 这是最关键的一步。它会使用 ConditionEvaluator (条件评估器) 来检查每个自动配置类上的 @ConditionalOn... 系列注解。只有当所有条件都满足（例如 @ConditionalOnClass 发现 classpath 中存在某个类），这个自动配置类才会被最终返回。

  5. 递归解析: 返回的自动配置类列表会被 ConfigurationClassParser 当作新的 @Configuration 类进行递归解析，它们内部定义的 @Bean 也会被注册为 BeanDefinition。

小结: @EnableAutoConfiguration 也是在 Bean 实例化之前 完成的。它利用了 Java 的 SPI 机制 (spring.factories) 和 Spring 的 @Conditional 注解，动态地、智能地将大量预置的 BeanDefinition 添加到 BeanFactory 中。

三、依赖注入的实现：@Autowired 与 @Value

当 BeanFactoryPostProcessor 完成工作后，BeanFactory 中已经有了所有 Bean 的定义。接下来，Spring 开始根据这些定义实例化 Bean。这时，BeanPostProcessor 登场了。

@Autowired 的注入过程

  1. 处理入口: AutowiredAnnotationBeanPostProcessor，它是一个 InstantiationAwareBeanPostProcessor，这是 BeanPostProcessor 的一个功能更强大的子接口。

  2. 寻找注入点: 当一个 Bean 实例化之后、属性填充之前，AutowiredAnnotationBeanPostProcessor的postProcessProperties方法会被调用。

    • 此方法会调用 findAutowiringMetadata 方法，利用反射扫描 Bean 的所有字段和方法，查找 @Autowired 和 @Value 注解。

    • 找到的注入点信息（比如是哪个字段，需要什么类型的 Bean）会被封装成一个 InjectionMetadata 对象，并被缓存起来，避免每次都反射扫描，提高性能。

  3. 执行注入: 拿到 InjectionMetadata 后，会调用其inject方法。

    • 内部会遍历所有的注入点元素（AutowiredFieldElement 或 AutowiredMethodElement）。

    • 对于每个注入点，它会调用 BeanFactory 的 resolveDependency 方法来获取需要注入的 Bean 实例。

    • resolveDependency 是依赖查找的核心，它会根据需要的类型 (Class) 和 @Qualifier 注解（如果有）去容器中寻找匹配的 Bean。它还能处理 Optional<T>、ObjectProvider<T> 以及 List<MyType> (注入所有 MyType 类型的 Bean) 等复杂情况。

  4. 反射赋值: 找到依赖的 Bean 之后，通过 Field.set(bean, injectedObject) 或 Method.invoke(bean, injectedObject) 将依赖注入到当前 Bean 中。

小结: @Autowired 的工作发生在Bean 实例化之后，由 AutowiredAnnotationBeanPostProcessor 驱动。它通过反射找到注入点，然后从 BeanFactory 中查找依赖的 Bean，最后再次通过反射完成赋值。

@Value 的解析过程

@Value 的处理流程与 @Autowired 几乎完全相同，因为它是由同一个 AutowiredAnnotationBeanPostProcessor 处理的。唯一的区别在于值的解析：

当处理器发现是 @Value("${...}") 注解时，它不会去 BeanFactory 中查找 Bean，而是调用 BeanFactory.resolveEmbeddedValue("${...}")。这个方法会委托给一个 StringValueResolver 来解析占位符。这个 Resolver 通常由 PropertySourcesPlaceholderConfigurer 提供，它会从 Spring 的 Environment 对象（封装了所有 application.properties、环境变量等）中查找相应的值。

四、Web 请求的响应：@RestController 与 @RequestMapping

Web 层的注解处理机制与核心容器略有不同，它由 DispatcherServlet 的 MVC 组件驱动。

  1. HandlerMapping 的初始化: Spring Boot 启动时，DispatcherServlet 会被创建。它会去容器中查找所有 HandlerMapping 类型的 Bean。Spring Boot 默认配置了 RequestMappingHandlerMapping。

  2. 扫描控制器: RequestMappingHandlerMapping 在其 afterPropertiesSet 初始化方法中，会扫描容器里所有被 @Controller 或 @RequestMapping 标记的 Bean。

  3. 创建映射关系:

    • 它会遍历这些 Bean 的所有方法，寻找 @RequestMapping (及其派生注解 @GetMapping, @PostMapping 等)。

    • 对于每个找到的方法，它会提取出 URL 路径、HTTP 方法、参数、请求头等信息，封装成一个 RequestMappingInfo 对象。

    • 然后，将 RequestMappingInfo 作为 Key，处理该请求的 HandlerMethod (包含了 Bean 实例和具体 Method 对象) 作为 Value，存入一个 Map 中。这个过程就是建立 URL 和处理方法之间的映射。

  4. 请求分发: 当一个 HTTP 请求到达 DispatcherServlet 时：

    • 它会遍历所有的 HandlerMapping，调用其 getHandler 方法，传入 HttpServletRequest。

    • RequestMappingHandlerMapping 会根据请求的 URL、HTTP 方法等信息，去自己的映射 Map 中查找对应的 HandlerMethod。

  5. 参数解析与方法调用:

    • DispatcherServlet 找到 HandlerMethod 后，会将其传递给 HandlerAdapter (通常是 RequestMappingHandlerAdapter)。

    • RequestMappingHandlerAdapter 负责调用HandlerMethod。在调用之前，它会使用一系列的HandlerMethodArgumentResolver

      来解析 Controller 方法的参数。

      • @RequestParam -> 由 RequestParamMethodArgumentResolver 处理。

      • @PathVariable -> 由 PathVariableMethodArgumentResolver 处理。

      • @RequestBody -> 由 RequestResponseBodyMethodProcessor 处理，它会使用 HttpMessageConverter (如 MappingJackson2HttpMessageConverter) 将请求体 JSON 反序列化为 Java 对象。

  6. 返回值处理:

    • 方法执行后，RequestMappingHandlerAdapter 还会使用 HandlerMethodReturnValueHandler 来处理返回值。

    • 如果方法或类上有 @ResponseBody 注解（@RestController 自带），RequestResponseBodyMethodProcessor (它既是参数解析器也是返回值处理器) 会被选中。它会再次使用 HttpMessageConverter 将返回的 Java 对象序列化为 JSON，并写入 HTTP 响应体。

总结

我们再快速梳理一下这条深度路径：

  1. 启动 -> BeanFactoryPostProcessor 阶段:

    • ConfigurationClassPostProcessor 启动。

    • 它解析 @ComponentScan，扫描并注册业务 Bean 的定义。

    • 它解析 @EnableAutoConfiguration，通过 spring.factories 和 @Conditional 加载并注册自动配置 Bean 的定义。

  2. 实例化 -> BeanPostProcessor 阶段:

    • BeanFactory 根据所有 BeanDefinition 创建实例。

    • AutowiredAnnotationBeanPostProcessor 登场，对已实例化的 Bean 进行处理。

    • 通过反射扫描 @Autowired 和 @Value，从容器中查找依赖或从配置中解析值，然后反射注入。

  3. Web 初始化 -> HandlerMapping 阶段:

    • RequestMappingHandlerMapping 扫描所有 @Controller，解析 @RequestMapping，建立 URL 与 HandlerMethod 的映射缓存。

  4. 运行时 -> DispatcherServlet 调度:

    • 请求进来，DispatcherServlet 使用 HandlerMapping 找到 HandlerMethod。

    • HandlerAdapter 调用 HandlerMethod，期间使用各种 ArgumentResolver 和 ReturnValueHandler 处理注解（@RequestBody, @ResponseBody 等）。

site logo

Hi,Ryu

© 2025 Ryu