Spring-依赖注入

最新推荐文章于 2023-05-30 10:08:22 发布

ligangit.com

最新推荐文章于 2023-05-30 10:08:22 发布

阅读量116

点赞数

分类专栏： Spring篇文章标签： spring Powered by 金山文档

本文链接：https://blog.csdn.net/qq_39338954/article/details/129337355

版权

Spring篇专栏收录该内容

7 篇文章 0 订阅

订阅专栏

Spring中依赖注入的方式

Spring中依赖注入分为两种：

手动注入

自动注入

手动注入

在xml中定义bean，由开发人员手动设置某个属性的值:

通过set方法进行注入：

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

通过构造方法进行注入：

<bean name="userService" class="com.luban.service.UserService">
 <constructor-arg index="0" ref="orderService"/>
</bean>

自动注入

方式一：XML的autowire

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

byType

获取到set方法中的唯一参数的参数类型，并且根据该类型去容器中获取bean;

找到多个，则报错

byName

找到所有set方法所对应的XXX部分的名字；

根据XXX部分的名字去获取bean

constructor

构造方法注入相当于byType+byName，通过构造方法中的参数类型去找bean，如果找到多个会根据参数名确定，找到bean之后作为参数传给构造方法，从而实例化得到一个bean对象，并完成属性赋

default

表示默认值，如果在<beans>标签中设置autowire，那么<bean>标签中设置的autowire如果为default，那么则会用<beans>标签中设置的autowire。

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xsi:schemaLocation="http://www.springframework.org/schema/beans
    http://www.springframework.org/schema/beans/spring-beans.xsd" default-autowire="byName">
</beans>

表示关闭autowire

<bean id="userService" class="com.luban.service.UserService" autowire="byType"/>

上述示例，表示Spring会自动的给userService中所有的属性自动赋值（需要有set方法）。

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

方式二：@Autowired注解

@Autowired注解，是byType和byName的结合。

@Autowired注解可以写在：

属性上：先根据属性类型去找Bean，如果找到多个再根据属性名确定一个

构造方法上：先根据方法参数类型去找Bean，如果找到多个再根据参数名确定一个

set方法上：先根据方法参数类型去找Bean，如果找到多个再根据参数名确定一个

而这种底层到了：

属性注入

set方法注入

构造方法注入

@Autowired注解优势

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

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

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

再举个例子，如果XML中指定的是byType+byName，那么会执行所有的set方法。

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

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

循环依赖

什么是循环依赖？

就是A对象依赖了B对象，B对象依赖了A对象。

在Spring中，一个对象并不是简单new出来了，而是会经过一系列的Bean的生命周期，就是因为Bean的生命周期所以才会出现循环依赖问题。

Bean的生成步骤如下：

Spring扫描class得到BeanDefinition

根据得到的BeanDefinition去生成bean

首先根据class推断构造方法

根据推断出来的构造方法，反射，得到一个对象（暂时叫做原始对象）

填充原始对象中的属性（依赖注入）

如果原始对象中的某个方法被AOP了，那么则需要根据原始对象生成一个代理对象

把最终生成的代理对象放入单例池（源码中叫做singletonObjects）中，下次getBean时就直接从单例池拿即可

可以看到，对于Spring中的Bean的生成过程，步骤还是很多的，并且不仅仅只有上面的7步，还有很多很多，比如Aware回调、初始化等等。

可以发现，在Spring中，构造一个Bean，包括了new这个步骤（第4步构造方法反射）。

得到一个原始对象后，Spring需要给对象中的属性进行依赖注入，那么这个注入过程是怎样的？

比如上文说的A类，A类中存在一个B类的b属性，所以，当A类生成了一个原始对象之后，就会去给b属性去赋值，此时就会根据b属性的类型和属性名去BeanFactory中去获取B类所对应的单例bean。如果此时BeanFactory中存在B对应的Bean，那么直接拿来赋值给b属性；如果此时BeanFactory中不存在B对应的Bean，则需要生成一个B对应的Bean，然后赋值给b属性。

问题就出现在第二种情况，如果此时B类在BeanFactory中还没有生成对应的Bean，那么就需要去生成，就会经过B的Bean的生命周期。

那么在创建B类的Bean的过程中，如果B类中存在一个A类的a属性，那么在创建B的Bean的过程中就需要A类对应的Bean，但是，触发B类Bean的创建的条件是A类Bean在创建过程中的依赖注入，所以这里就出现了循环依赖：

ABean创建-->依赖了B属性-->触发BBean创建--->B依赖了A属性--->需要ABean（但ABean还在创建过程中）

从而导致ABean创建不出来，BBean也创建不出来。

这是循环依赖的场景，在Spring中，通过某些机制帮开发者解决了部分循环依赖的问题，这个机制就是三级缓存。

三级缓存

三级缓存是通用的叫法。一级缓存为：singletonObjects二级缓存为：earlySingletonObjects三级缓存为：singletonFactories

解释一下这三个缓存的作用：

singletonObjects中缓存的是已经经历了完整生命周期的bean对象。

earlySingletonObjects比singletonObjects多了一个early，表示缓存的是早期的bean对象。早期是什么意思？表示Bean的生命周期还没走完就把这个Bean放入了earlySingletonObjects。

singletonFactories中缓存的是ObjectFactory，表示对象工厂，表示用来创建早期bean对象的工厂。

A的Bean在创建过程中，在进行依赖注入之前，先把A的原始Bean放入缓存（提早暴露，只要放到缓存了，其他Bean需要时就可以从缓存中拿了），放入缓存后，再进行依赖注入，此时A的Bean依赖了B的Bean，如果B的Bean不存在，则需要创建B的Bean，而创建B的Bean的过程和A一样，也是先创建一个B的原始对象，然后把B的原始对象提早暴露出来放入缓存中，然后在对B的原始对象进行依赖注入A，此时能从缓存中拿到A的原始对象（虽然是A的原始对象，还不是最终的Bean），B的原始对象依赖注入完了之后，B的生命周期结束，那么A的生命周期也能结束。

因为整个过程中，都只有一个A原始对象，所以对于B而言，就算在属性注入时，注入的是A原始对象，也没有关系，因为A原始对象在后续的生命周期中在堆中没有发生变化。

从上面这个分析过程中可以得出，只需要一个缓存就能解决循环依赖了，那么为什么Spring中还需要singletonFactories呢？

这是难点，基于上面的场景想一个问题：如果A的原始对象注入给B的属性之后，A的原始对象进行了AOP产生了一个代理对象，此时就会出现，对于A而言，它的Bean对象其实应该是AOP之后的代理对象，而B的a属性对应的并不是AOP之后的代理对象，这就产生了冲突。

B依赖的A和最终的A不是同一个对象。

AOP就是通过一个BeanPostProcessor来实现的，这个BeanPostProcessor就是AnnotationAwareAspectJAutoProxyCreator，它的父类是AbstractAutoProxyCreator，而在Spring中AOP利用的要么是JDK动态代理，要么CGLib的动态代理，所以如果给一个类中的某个方法设置了切面，那么这个类最终就需要生成一个代理对象。

一般过程就是：A类--->生成一个普通对象-->属性注入-->基于切面生成一个代理对象-->把代理对象放入singletonObjects单例池中。

而AOP可以说是Spring中除开IOC的另外一大功能，而循环依赖又是属于IOC范畴的，所以这两大功能想要并存，Spring需要特殊处理。

如何处理的，就是利用了第三级缓存singletonFactories。

首先，singletonFactories中存的是某个beanName对应的ObjectFactory，在bean的生命周期中，生成完原始对象之后，就会构造一个ObjectFactory存入singletonFactories中。这个ObjectFactory是一个函数式接口，所以支持Lambda表达式：() -> getEarlyBeanReference(beanName, mbd, bean)

上面的Lambda表达式就是一个ObjectFactory，执行该Lambda表达式就会去执行。

getEarlyBeanReference方法：

首先得到一个cachekey，cachekey就是beanName；

然后把beanName和bean（这是原始对象）存入earlyProxyReferences中；

调用wrapIfNecessary进行AOP，得到一个代理对象。

总结一下三级缓存

singletonObjects：缓存经过了完整生命周期的bean

earlySingletonObjects：缓存未经过完整生命周期的bean，如果某个bean出现了循环依赖，就会提前把这个暂时未经过完整生命周期的bean放入earlySingletonObjects中，这个bean如果要经过AOP，那么就会把代理对象放入earlySingletonObjects中，否则就是把原始对象放入earlySingletonObjects，但是不管怎么样，就是是代理对象，代理对象所代理的原始对象也是没有经过完整生命周期的，所以放入earlySingletonObjects我们就可以统一认为是未经过完整生命周期的bean。存放的是三级缓存中lambda执行后的结果

singletonFactories：缓存的是一个ObjectFactory，也就是一个Lambda表达式。在每个Bean的生成过程中，经过实例化得到一个原始对象后，都会提前基于原始对象暴露一个Lambda表达式，并保存到三级缓存中，这个Lambda表达式可能用到，也可能用不到，如果当前Bean没有出现循环依赖，那么这个Lambda表达式没用，当前bean按照自己的生命周期正常执行，执行完后直接把当前bean放入singletonObjects中，如果当前bean在依赖注入时发现出现了循环依赖（当前正在创建的bean被其他bean依赖了），则从三级缓存中拿到Lambda表达式，并执行Lambda表达式得到一个对象，并把得到的对象放入二级缓存（(如果当前Bean需要AOP，那么执行lambda表达式，得到就是对应的代理对象，如果无需AOP，则直接得到一个原始对象)）。