4.依赖注入

玉袍长剑(xiexy)

已于 2023-02-22 14:26:52 修改

阅读量149

点赞数

分类专栏： spring 文章标签： spring

于 2022-11-29 00:34:49 首次发布

本文链接：https://blog.csdn.net/javahacker2/article/details/128089938

版权

spring 专栏收录该内容

13 篇文章 0 订阅

订阅专栏

一、依赖注入的方式

首先分两种:

1. 手动注入
2. 自动注入

1.1.手动注入

在XML中定义Bean时，就是手动注入，因为是程序员手动给某个属性指定了值。

  <bean name="userService" class="com.luban.service.UserService">
      <property name="orderService" ref="orderService"/>
  </bean>

上面这种底层是通过set方法进行注入。

  <bean name="userService" class="com.luban.service.UserService">
      <constructor‐arg index="0" ref="orderService"/>
  </bean>
上面这种底层是通过构造方法进行注入。
所以手动注入的底层也就是分为两种:

1. set方法注入
2. 构造方法注入

1.2.自动注入

自动注入又分为两种:

1. XML的autowire自动注入
2. @Autowired注解的自动注入

1.2.1XML的autowire自动注入

在XML中，我们可以在定义一个Bean时去指定这个Bean的自动注入模式:

1. byType
2. byName
3. constructor
4. default
5. no

比如:

这么写，表示Spring会自动的给userService中所有的属性自动赋值(不需要这个属性上有

@Autowired注解，但需要这个属性有对应的set方法)。

在创建Bean的过程中，在填充属性时，Spring会去解析当前类，把当前类的所有方法都解析出来， Spring会去解析每个方法得到对应的PropertyDescriptor对象，PropertyDescriptor中有几个属性:

name:这个name并不是方法的名字，而是拿方法名字进过处理后的名字
i. 如果方法名字以“get”开头，比如“getXXX”,那么name=XXX

ii. 如果方法名字以“is”开头，比如“isXXX”,那么name=XXX

iii. 如果方法名字以“set”开头，比如“setXXX”,那么name=XXX

readMethodRef:表示get方法的Method对象的引用
readMethodName:表示get方法的名字
writeMethodRef:表示set方法的Method对象的引用
writeMethodName:表示set方法的名字
propertyTypeRef:如果有get方法那么对应的就是返回值的类型，如果是set方法那么对应的就是set方法中唯一参数的类型

get方法的定义是: 方法参数个数为0个，并且 (方法名字以"get"开头或者方法名字以"is"开头并且方法的返回类型为boolean)

**set方法的定义是:**方法参数个数为1个，并且 (方法名字以"set"开头并且方法返回类型为 void)

所以，Spring在通过byName的自动填充属性时流程是:

1. 找到所有set方法所对应的XXX部分的名字 2. 根据XXX部分的名字去获取bean

Spring在通过byType的自动填充属性时流程是:

1. 获取到set方法中的唯一参数的参数类型，并且根据该类型去容器中获取bean 2. 如果找到多个，会报错。

以上，分析了autowire的byType和byName情况，那么接下来分析constructor，constructor表示通过构造方法注入，其实这种情况就比较简单了，没有byType和byName那么复杂。

如果是constructor，那么就可以不写set方法了，当某个bean是通过构造方法来注入时，spring利用构造方法的参数信息从Spring容器中去找bean，找到bean之后作为参数传给构造方法，从而实例化得到一个bean对象，并完成属性赋值(属性赋值的代码得程序员来写)。

我们这里先不考虑一个类有多个构造方法的情况，后面单独讲推断构造方法。我们这里只考虑只有一
个有参构造方法。

其实构造方法注入相当于byType+byName，普通的byType是根据set方法中的参数类型去找 bean，找到多个会报错，而constructor就是通过构造方法中的参数类型去找bean，如果找到多个会根据参数名确定。

另外两个:

1. no，表示关闭autowire

2. default，表示默认值，我们一直演示的某个bean的autowire，而也可以直接在<beans>标签中设置autowire，如果设置了，那么<bean>标签中设置的autowire如果为default，那么则会用 <beans>标签中设置的autowire。

可以发现XML中的自动注入是挺强大的，那么问题来了，为什么我们平时都是用的@Autowired注解呢?而没有用上文说的这种自动注入方式呢?

@Autowired注解相当于XML中的autowire属性的注解方式的替代。这是在官网上有提到的。

  Essentially, the @Autowired annotation provides the same capabilities as described in
  Autowiring Collaborators but with more fine‐grained control and wider applicability

翻译一下: 从本质上讲，@Autowired注解提供了与autowire相同的功能，但是拥有更细粒度的控制和更广泛的适用性。

注意:更细粒度的控制。

XML中的autowire控制的是整个bean的所有属性，而@Autowired注解是直接写在某个属性、某个 set方法、某个构造方法上的。

再举个例子，如果一个类有多个构造方法，那么如果用XML的autowire=constructor，你无法控制到底用哪个构造方法，而你可以用@Autowired注解来直接指定你想用哪个构造方法。

同时，用@Autowired注解，还可以控制，哪些属性想被自动注入，哪些属性不想，这也是细粒度的控制。

但是@Autowired无法区分byType和byName，@Autowired是先byType，如果找到多个则 byName。

那么XML的自动注入底层其实也就是:

1. set方法注入

2. 构造方法注入

@Autowired注解的自动注入

上文说了@Autowired注解，是byType和byName的结合。 @Autowired注解可以写在:

1. 属性上:先根据属性类型去找Bean，如果找到多个再根据属性名确定一个
2. 构造方法上:先根据方法参数类型去找Bean，如果找到多个再根据参数名确定一个
3. set方法上:先根据方法参数类型去找Bean，如果找到多个再根据参数名确定一个

而这种底层到了:

1. 属性注入
2. set方法注入
3. 构造方法注入

寻找注入点

在创建一个Bean的过程中，Spring会利用AutowiredAnnotationBeanPostProcessor的 **postProcessMergedBeanDefinition()**找出注入点并缓存，找注入点的流程为:

遍历当前类的所有的属性字段Field
查看字段上是否存在@Autowired、@Value、@Inject中的其中任意一个，存在则认为该字段是一个注入点
如果字段是static的，则不进行注入
获取@Autowired中的required属性的值
将字段信息构造成一个AutowiredFieldElement对象，作为一个注入点对象添加到 currElements集合中。
遍历当前类的所有方法Method
判断当前Method是否是桥接方法，如果是找到原方法
查看方法上是否存在@Autowired、@Value、@Inject中的其中任意一个，存在则认为该方法是一个注入点
如果方法是static的，则不进行注入
获取@Autowired中的required属性的值
将方法信息构造成一个AutowiredMethodElement对象，作为一个注入点对象添加到 currElements集合中。
遍历完当前类的字段和方法后，将遍历父类的，直到没有父类。
最后将currElements集合封装成一个InjectionMetadata对象，作为当前Bean对于的注入点集合对象，并缓存。

static的字段或方法为什么不支持

  @Component
  @Scope("prototype")
  public class OrderService {

}

  @Component
  @Scope("prototype")
  public class UserService  {

@Autowired

      private static OrderService orderService;

      public void test() {
          System.out.println("test123");

} }

看上面代码，UserService和OrderService都是原型Bean，假设Spring支持static字段进行自动注入，那么现在调用两次

1. UserService userService1 = context.getBean("userService") 2. UserService userService2 = context.getBean("userService")

问此时，userService1的orderService值是什么?还是它自己注入的值吗?

答案是不是，一旦userService2 创建好了之后，static orderService字段的值就发生了修改了，从而出现bug。

桥接方法

public interface UserInterface<T> {
      void setOrderService(T t);

}

@Component

  public class UserService implements UserInterface<OrderService> {

      private OrderService orderService

      @override
      @autowired
      public void setOrderService(OrderService orderService) {
          this.orderService = orderService;

}

      public void test() {
          System.out.println("test123");

} }

可以看到在UserSerivce的字节码中有两个setOrderService方法:

1. public setOrderService(Lcom/zhouyu/service/OrderService;)V

2. public synthetic bridge setOrderService(Ljava/lang/Object;)V

并且都是存在@Autowired注解的。所以在Spring中需要处理这种情况，当遍历到桥接方法时，得找到原方法。

注入点进行注入

Spring在AutowiredAnnotationBeanPostProcessor的**postProcessProperties()**方法中，会遍历所找到的注入点依次进行注入。

字段注入

遍历所有的AutowiredFieldElement对象。
将对应的字段封装为DependencyDescriptor对象。
调用BeanFactory的resolveDependency()方法，传入DependencyDescriptor对象，进行依赖查找，找到当前字段所匹配的Bean对象。
将DependencyDescriptor对象和所找到的结果对象beanName封装成一个 ShortcutDependencyDescriptor对象作为缓存，比如如果当前Bean是原型Bean，那么下次再来创建该Bean时，就可以直接拿缓存的结果对象beanName去BeanFactory中去那bean对象了，不用再次进行查找了
利用反射将结果对象赋值给字段。

Set方法注入

遍历所有的AutowiredMethodElement对象
遍历将对应的方法的参数，将每个参数封装成MethodParameter对象
将MethodParameter对象封装为DependencyDescriptor对象
调用BeanFactory的resolveDependency()方法，传入DependencyDescriptor对象，进行依赖查找，找到当前方法参数所匹配的Bean对象。
将DependencyDescriptor对象和所找到的结果对象beanName封装成一个 ShortcutDependencyDescriptor对象作为缓存，比如如果当前Bean是原型Bean，那么下次再来创建该Bean时，就可以直接拿缓存的结果对象beanName去BeanFactory中去那bean对象了，不用再次进行查找了
利用反射将找到的所有结果对象传给当前方法，并执行。

resolveDependency

Spring中的自动注入(byName,byType)和@Autowired注解的工作原理以及源码分析,剩下的核心的方法:

@Nullable

Object resolveDependency(DependencyDescriptor descriptor, @Nullable String
requestingBeanName,
@Nullable Set<String> autowiredBeanNames, @Nullable TypeConverter typeConverter)
throws BeansException;
该方法表示，传入一个依赖描述(DependencyDescriptor)，该方法会根据该依赖描述从 BeanFactory中找出对应的唯一的一个Bean对象。

具体流程图: https://www.processon.com/view/link/5f8d3c895653bb06ef076688

findAutowireCandidates()实现

找出BeanFactory中类型为type的所有的Bean的名字，注意是名字，而不是Bean对象，因为我们可以根据BeanDefinition就能判断和当前type是不是匹配，不用生成Bean对象

把resolvableDependencies中key为type的对象找出来并添加到result中

遍历根据type找出的beanName，判断当前beanName对应的Bean是不是能够被自动注入

先判断beanName对应的BeanDefinition中的autowireCandidate属性，如果为false，表示不能用来进行自动注入，如果为true则继续进行判断

判断当前type是不是泛型，如果是泛型是会把容器中所有的beanName找出来的，如果是这种情况，那么在这一步中就要获取到泛型的真正类型，然后进行匹配，如果当前beanName和当前泛型对应的真实类型匹配，那么则继续判断

如果当前DependencyDescriptor上存在@Qualifier注解，那么则要判断当前beanName上是否定义了Qualifier，并且是否和当前DependencyDescriptor上的Qualifier相等，相等则匹配

经过上述验证之后，当前beanName才能成为一个可注入的，添加到result中

关于依赖注入中泛型注入的实现

首先在Java反射中，有一个Type接口，表示类型，具体分类为:

1. raw types:也就是普通Class
2. parameterized types:对应ParameterizedType接口，泛型类型
3. array types:对应GenericArrayType，泛型数组
4. type variables:对应TypeVariable接口，表示类型变量，也就是所定义的泛型，比如T、K
5. primitive types:基本类型，int、boolean

大家可以好好看看下面代码所打印的结果:
public class TypeTest<T> {
private int i;
private Integer it;
private int[] iarray;
private List list;
private List<String> slist;
private List<T> tlist;
private T t;
private T[] tarray;
public static void main(String[] args) throws NoSuchFieldException {
test(TypeTest.class.getDeclaredField("i"));
System.out.println("=======");
test(TypeTest.class.getDeclaredField("it"));
System.out.println("=======");
test(TypeTest.class.getDeclaredField("iarray"));
System.out.println("=======");
test(TypeTest.class.getDeclaredField("list"));
System.out.println("=======");
test(TypeTest.class.getDeclaredField("slist"));
System.out.println("=======");
test(TypeTest.class.getDeclaredField("tlist"));
System.out.println("=======");
test(TypeTest.class.getDeclaredField("t"));
System.out.println("=======");
test(TypeTest.class.getDeclaredField("tarray"));
}
public static void test(Field field) {
if (field.getType().isPrimitive()) { System.out.println(field.getName() + "是基本数据类型");

} else {
System.out.println(field.getName() + "不是基本数据类型");

}

if (field.getGenericType() instanceof ParameterizedType) { System.out.println(field.getName() + "是泛型类型");

} else {
System.out.println(field.getName() + "不是泛型类型");

}

if (field.getType().isArray()) { System.out.println(field.getName() + "是普通数组");

} else {
System.out.println(field.getName() + "不是普通数组");

}

if (field.getGenericType() instanceof GenericArrayType) { System.out.println(field.getName() + "是泛型数组");

} else {
System.out.println(field.getName() + "不是泛型数组");

}

if (field.getGenericType() instanceof TypeVariable) { System.out.println(field.getName() + "是泛型变量");

} else {
System.out.println(field.getName() + "不是泛型变量");

} }

}

Spring中，但注入点是一个泛型时，也是会进行处理的，比如:

@Component

public class UserService extends BaseService<OrderService, StockService> {
public void test() {
System.out.println(o);
} }

public class BaseService<O, S> {
@Autowired
protected O o;
@Autowired

protected S s;
}
Spring扫描时发现UserService是一个Bean

那就取出注入点，也就是BaseService中的两个属性o、s

接下来需要按注入点类型进行注入，但是o和s都是泛型，所以Spring需要确定o和s的具体类型。

因为当前正在创建的是UserService的Bean，所以可以通过 userService.getClass().getGenericSuperclass().getTypeName() 获取到具体的泛型信息，比如 com.zhouyu.service.BaseService<com.zhouyu.service.OrderService,

com.zhouyu.service.StockService>
然后再拿到UserService的父类BaseService的泛型变量: for (TypeVariable<? extends Class<? >> typeParameter : userService.getClass().getSuperclass().getTypeParameters()) { System._out_.println(typeParameter.getName()); }

6. 通过上面两段代码，就能知道，o对应的具体就是OrderService，s对应的具体类型就是 StockService

7. 然后再调用 oField.getGenericType() 就知道当前field使用的是哪个泛型，就能知道具体类型了