Spring5源码分析系列（六）基于注解的依赖注入

浅浅的花香味﹌ 2022-05-08 00:54 263阅读 0赞

紧接上文基于XML的依赖注入，本文开始讲解基于注解的依赖注入，文章参考自Tom老师的视频。

### 基于Annotation的依赖注入 ###

1.从Spring2.0以后的版本中，Spring也引入了基于注解(Annotation)方式的配置，注解(Annotation)是JDK1.5中引入的一个新特性，用于简化Bean的配置，某些场合可以取代XML配置文件。开发人员对注解(Annotation)的态度也是萝卜青菜各有所爱，个人认为注解可以大大简化配置，提高开发速度，同时也不能完全取代XML配置方式，XML方式更加灵活，并且发展的相对成熟，这种配置方式为大多数Spring开发者熟悉；注解方式使用起来非常简洁，但是尚处于发展阶段，XML配置文件和注解(Annotation)可以相互配合使用。

SpringIOC容器对于类级别的注解和类内部的注解分以下两种处理策略：

(1).类级别的注解：如@Component、@Repository、@Controller、@Service以及JavaEE6的@ManagedBean和@Named注解，都是添加在类上面的类级别注解，Spring容器根据注解的过滤规则扫描读取注解Bean定义类，并将其注册到SpringIOC容器中。

(2).类内部的注解：如@Autowire、@Value、@Resource以及EJB和WebService相关的注解等，都是添加在类内部的字段或者方法上的类内部注解，SpringIOC容器通过Bean后置注解处理器解析Bean内部的注解。

下面将根据这两种处理策略，分别分析Spring处理注解相关的源码。

2.AnnotationConfigApplicationContext对注解Bean初始化：

Spring中，管理注解Bean定义的容器有两个：AnnotationConfigApplicationContext和AnnotationConfigWebApplicationContex。这两个类是专门处理Spring注解方式配置的容器，直接依赖于注解作为容器配置信息来源的IOC容器。AnnotationConfigWebApplicationContext是AnnotationConfigApplicationContext的web版本，两者的用法以及对注解的处理方式几乎没有什么差别。

现在来看看AnnotationConfigApplicationContext的源码：

![70][]![70 1][]

通过对AnnotationConfigApplicationContext的源码分析，我们了解到Spring对注解的处理分为两种方式：

(1).直接将注解Bean注册到容器中：

可以在初始化容器时注册；也可以在容器创建之后手动调用注册方法向容器注册，然后通过手动刷新容器，使得容器对注册的注解Bean进行处理。

(2).通过扫描指定的包及其子包下的所有类：

在初始化注解容器时指定要自动扫描的路径，如果容器创建以后向给定路径动态添加了注解Bean，则需要手动调用容器扫描的方法，然后手动刷新容器，使得容器对所注册的Bean进行处理。

接下来，将会对两种处理方式详细分析其实现过程。

3.AnnotationConfigApplicationContext注册注解Bean：

当创建注解处理容器时，如果传入的初始参数是具体的注解Bean定义类时，注解容器读取并注册。

(1).AnnotationConfigApplicationContext通过调用注解Bean定义读取器AnnotatedBeanDefinitionReader的register方法向容器注册指定的注解Bean，注解Bean定义读取器向容器注册注解Bean的源码如下：

![70 2][]

![70 3][]

![70 4][]

从上面的源码我们可以看出，注册注解Bean定义类的基本步骤：

a，需要使用注解元数据解析器解析注解Bean中关于作用域的配置。

b，使用AnnotationConfigUtils的processCommonDefinitionAnnotations方法处理注解Bean定义类中通用的注解。

c，使用AnnotationConfigUtils的applyScopedProxyMode方法创建对于作用域的代理对象。

d，通过BeanDefinitionReaderUtils向容器注册Bean。

下面我们继续分析这3步的具体实现过程

(2).AnnotationScopeMetadataResolver解析作用域元数据：

AnnotationScopeMetadataResolver通过processCommonDefinitionAnnotations方法解析注解Bean定义类的作用域元信息，即判断注册的Bean是原生类型(prototype)还是单态(singleton)类型，其源码如下：

![70 5][]上述代码中的annDef.getMetadata().getAnnotationAttributes方法就是获取对象中指定类型的注解的值。

(3).AnnotationConfigUtils处理注解Bean定义类中的通用注解：

AnnotationConfigUtils类的processCommonDefinitionAnnotations在向容器注册Bean之前，首先对注解Bean定义类中的通用Spring注解进行处理，源码如下：

![70 6][]

(4).AnnotationConfigUtils根据注解Bean定义类中配置的作用域为其应用相应的代理策略：

AnnotationConfigUtils类的applyScopedProxyMode方法根据注解Bean定义类中配置的作用域@Scope注解的值，为Bean定义应用相应的代理模式，主要是在Spring面向切面编程(AOP)中使用。源码如下：

![70 7][]

这段为Bean引用创建相应模式的代理，这里不做深入的分析。

(5).BeanDefinitionReaderUtils向容器注册Bean：

BeanDefinitionReaderUtils向容器注册载入的Bean我们在第4篇博客中已经分析过，主要是校验Bean定义，然后将Bean添加到容器中一个管理Bean定义的HashMap中，这里就不做分析。

4.AnnotationConfigApplicationContext扫描指定包及其子包下的注解Bean：

当创建注解处理容器时，如果传入的初始参数是注解Bean定义类所在的包时，注解容器将扫描给定的包及其子包，将扫描到的注解Bean定义载入并注册。

(1).ClassPathBeanDefinitionScanner扫描给定的包及其子包：

AnnotationConfigApplicationContext通过调用类路径Bean定义扫描器ClassPathBeanDefinitionScanner扫描给定包及其子包下的所有类，主要源码如下：

![70 8][]

![70 9][]

![70 10][]

类路径Bean定义扫描器ClassPathBeanDefinitionScanner主要通过findCandidateComponents方法调用其父类ClassPathScanningCandidateComponentProvider类来扫描获取给定包及其子包下的类。

(2).ClassPathScanningCandidateComponentProvider扫描给定包及其子包的类：

ClassPathScanningCandidateComponentProvider类的findCandidateComponents方法具体实现扫描给定类路径包的功能，主要源码如下：

![70 11][]

![70 12][]![70 13][]![70 14][]5.AnnotationConfigWebApplicationContext载入注解Bean定义：

AnnotationConfigWebApplicationContext是AnnotationConfigApplicationContext的Web版，它们对于注解Bean的注册和扫描是基本相同的，但是AnnotationConfigWebApplicationContext对注解Bean定义的载入稍有不同，AnnotationConfigWebApplicationContext注入注解Bean定义源码如下：

![70 15][]

![70 16][]

解析和注入注解配置资源的过程分析

[70]: https://img-blog.csdn.net/20181008123951969?watermark/2/text/aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2h1eWFuZzAzMDQ=/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70
[70 1]: /images/20220508/0b9d964fc07a408f9621fe6a8362393e.png
[70 2]: /images/20220508/9b5dd90a94724b9083ad7ba9bb683152.png
[70 3]: /images/20220508/ad4e1b6dcc8e476eba9c7f47fcd59936.png
[70 4]: /images/20220508/7b70ff582f00416d98d2a46617e5c6e9.png
[70 5]: /images/20220508/6aa36e0a67484a43ad91f44e95489589.png
[70 6]: /images/20220508/afe66e69dc084538a9d1b9e56b341a95.png
[70 7]: /images/20220508/85cf18d463a148328d963a4def35ee70.png
[70 8]: /images/20220508/1b7e2d6833a442278868c1e08da4cb65.png
[70 9]: /images/20220508/bab0dc66cf1743e385b090c485feb1d0.png
[70 10]: /images/20220508/891705dae11e42c9b734a2eabe48306c.png
[70 11]: /images/20220508/147e8e1f3248409da713974f9563f1fc.png
[70 12]: https://img-blog.csdn.net/20181008124338416?watermark/2/text/aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2h1eWFuZzAzMDQ=/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70
[70 13]: https://img-blog.csdn.net/20181008124338153?watermark/2/text/aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2h1eWFuZzAzMDQ=/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70
[70 14]: /images/20220508/23d2662c4c7c4d228045104dc5a7ad4d.png
[70 15]: /images/20220508/9c9aaa1e6f8a4b1e93d0c123cae9a143.png
[70 16]: /images/20220508/988b95b91ff54ae092efcdfdbd2d7fb6.png