标签:bean 兼容 setter 获取 false work cap pid 仓库
IOC(Inversion of Control) 控制反转,也叫 DI(D_ependency injection_) 依赖注入。是一种设计思想。不过我并不同意所谓反转的说法,因为没有谁规定什么方式就是“标准”的,如果我把IOC作为“标准”,IOC就是“标准”自身,何来反转?不过我行文也是沿用官方的说法,使用IOC描述这个技术
IOC其实是一种组装的思想,最简单理解 IOC 的方法,就是我们的组装电脑。
主板,硬盘,显卡,CPU厂商们先定义好一个个插口。
然后主板厂商就在他的主板上面预留位置。比如 A 插口是 留给硬盘的,B插口是留给 CPU的。注意,主板生产完成时,硬盘和CPU并没有在主板上,而是空的,不过主板已经写好好了给 CPU 和 硬盘 供电的 功能。
我们的工作就是根据主板的插口来找件,装配,而不是先买CPU、内存、硬盘再去选主板,这就是IOC ,主板需要插什么接口的,我们就去获得相关的零件,这样整个电脑就可以工作。
首先,我们必须要知道,没有 Spring ,我们照样可以做所谓的 IOC,就是 主物预留插口 -> 按插口找件,组装。其实这在我们生活中随处可见。
那么,我们为什么要使用 Spring 呢,我们组装电脑,就要获得关于这个电脑的所有部件,比如主板、电源、内存等等,我们自己当然不可能凭空造出来,但是我们可以上商城购买,我们只需要关心接口对不对,而不用关心他是怎么生产的。那么,Spring 的角色就是一个商城。
我们可以把 Spring IOC 看成一个全产业链的商城,他会把产业链中的第一层原料开始,每一层都登记进入商城。在这个商城里面,我们可以买到任何层级的零件。之后,我们就可以自由的控制一切:如果我们是厂商,我们可以买到我们想要的零件。如果我们是消费者,想组装电脑,就可以买到主板,硬盘和CPU。如果我们有了机房,就可以直接买到若干个电脑。甚至,我们有一个国家,就可以在上面买到关于这个国家的一切。我们再不用关心东西是怎么来的,我们只管买即可。东西生产由其他人负责。而Spring IOC做的就是整个产业链从头到尾的组装,上架工作。
Spring IOC的好处也是众说纷纭,我也没有找到很有说服力的解释,姑且写一些在下面:
轻松实现面向接口编程,中心管理,按需取用,各个环节完全解耦,比如,网站环境和测试环境差异巨大,也可以轻松切换。
可以监听和控制所管理对象的生命周期,并且执行相关的操作
因为可以控制对象的生命周期,所以可以轻松通过 AOP 进行对象增强
轻松整合整个 Java 生态链,对于开发者来说,整合是轻松友好的。
随着 SpringBoot 的潮流, 我们坚持只使用注解配置 Spring IOC
maven 配置依赖
1
|
<dependency>
|
spring-context 会自动将 spring-core、spring-beans、spring-aop、spring-expression 这几个基础 jar 包带进来。
定义一个接口 (类比的话,就是主物上面的一个接口)
1
|
public interface MessageService {
|
定义接口实现类(类比的话,就是零件自身),并且使用注解注册到 Spring 商城
1
|
|
使用: (类比的话,就是从商城买东西) (这里没有使用依赖注入(自动装配),下面会介绍)
1
|
// Main.java
|
Spring中管理的对象都叫 Bean,就像商城里面的一种商品。Spring 管理的对象默认是单例的,也就是一种商品只有一件,不过可以重复购买(注入)。下面,我们说一下如何上架这些商品。
@Component 通用的登记方式,以下的注解都包含这个注解的功能,并且可能有额外的含义
@Service 通常用于服务层
@Controller 通常用于控制层
@Repository 通常用于数据库仓库层
后面加(“”) 定义 bean 的名字,也可以不定义自动由 Spring 生成。
例子:
1
|
|
我们有时候想通过一个工厂的方式,根据传入不同对象,生成不同的对象,并登记到 Spring,我们要这么做
1
|
|
我们现在就注册到了一个 redisTemplate 的 Bean,是通过我们的配置文件生产的。
其中有这些注解
@Configuration 说明这是个配置类
@Bean 说明这个函数是用来创建 Bean 的
@Qualifier 说明我们引入哪一个 Bean 作为 传入参数。
我们可以写多组这样的函数,就会创造出不同的 Bean
另外还有可能用到的是 @Lazy ,可以让 bean 在用的时候再加载。
当然,除了上面的 getBean 外,Spring还给我们封装了许多方法方便我们买东西:
其中,@Autowired 注解 最常用,意思是按类型装配,如果这个类型的零件只有一个,那么就默认选这一个。如果是有多个,那么还需要我们指定具体是哪一个。
1
|
|
1
|
|
1
|
|
如果一个类型对应多个 Bean,使用 @Qualifier 指定
1
|
|
Spring IOC生命周期:
初始化 BeanFactory
创建 BeanFactory
读取 BeanDefinition
通过BeanDefinition,初始化 Bean
供外部调用
BeanFactory销毁
我们可以在 Spring IOC 的生命周期中置入各种我们自定义的逻辑。
单独类实现接口,一般是应用于全局的
Bean 继承 Aware 类,一般是用于该 Bean 获取环境变量
Bean 实现 接口,一般是用于该 Bean
Bean 上 注解,一般是用于该 Bean
实现 BeanFactoryPostProcessor 在BeanFactory初始化之后(已经读取了配置但还没初始化Bean),做一些操作,可以读取并修改BeanDefinition
1
|
|
顺序如下:
开始几步分别是:实例化、构造函数、设置属性函数,并且,在这里,其实Spring早就已经把所有属性都注入好了,下面的过程都是 Spring 预留给用户扩展的。
BeanNameAware抽象类 可以 获取到 BeanName,其他几个 Aware 类似
1
|
|
BeanPostProcessor接口 对每一个 Bean 初始化前后进行置入,有多少个 Bean 就会执行多少次
postProcessBeforeInitialization(Object bean, String beanName)
postProcessAfterInitialization(Object bean, String beanName)
@PostConstruct 注解(在Bean上),用户自定义的该Bean的初始化操作
InitializingBean接口的afterPropertiesSet()方法会被调用
init-method 用注解的话,这个一般不用了,一定要用的话,可以用 @Bean(initMethod = “initMethodName”),在配置中心配置,不能在 Bean 上配置。
Bean 是 Spring 里面最基本的单位,如果把 Spring 管理的对象看成一群人,那么 Bean 就是每一个人。
在用户看来,bean 就是一个实际的对象,比如
1
|
MessageService messageService = context.getBean(MessageService.class);
|
在Spring内部,Bean的本质是一个 BeanName -> BeanDefinition 的键值对 ,即用于搜索的名字,和他的实际定义内容。
比如:
1
|
<bean id="messageService" class="ma.luan.example.MessageServiceImpl"/>
|
就定义了一个 Bean,Name 是 messageService ,BeanDefinition 的内容之一是 ma.luan.example.MessageServiceImpl
Spring IOC 的门面,供用户调用,起到统筹全局的作用。背后它从源(Resource)读取配置 ,为每个 bean 生成配置对象(BeanDefinition) 到工厂(BeanFactory)的注册中心(Registry) ,控制工厂管理 Bean (Autowire),代理工厂的 getBean 操作。我们可以使用多种输入方式 Context。
Spring 的核心,他管理着一个注册中心 Registry,并且负责管理 Bean(加载类,实例化,注入属性等),并且提供 getBean 等操作
BeanFactory: 可以获取一个 Bean 的能力的接口,有getBean方法
ListableBeanFactory,有一次获取多个 Bean 能力的接口,有getBeans方法
HierarchicalBeanFactory,有继承能力的工厂接口,有一个 getParentBeanFactory 方法,可以获取父工厂,先不用管
AutowireCapableBeanFactory 可以自动装配的工厂接口,继承它让我们的工厂可以对 Bean 自动创建,属性进行自动插入的能力。autowireBean、createBean、initializeBean、applyBeanPostProcessorsBeforeInitialization 等等,是工厂最核心的能力
DefaultListableBeanFactory,继承了所有接口,是我们最常使用的标准工厂。他继承并实现了所有的能力
getBean
getBeans
getParentBeanFactory
AutowireCapable
Config (修改设置)
ApplicationContext虽然也继承了 BeanFactory,但是实际上是复用了他的 getBean() 等接口,实际逻辑代码并没有什么继承关系。
注册中心,维护着多个 Map,用于登记 Bean 的信息,包括 BeanDefinition 的 Map,还有 存放单例的 singletonObjects 的 Map 等等。
BeanDefinition存放我们在配置文件中对某个 Bean 的所有注册信息,和存放该对象的实际单例对象。
比如,
我们在 xml 文件中配置
1
|
<bean id="messageService" class="ma.luan.example.MessageServiceImpl"/>
|
那么, BeanRegistry 中 会有
messageService -> BeanDefinition
BeanDefinition里面有关于这个 Bean 的所有配置
负责从多个配置源(Resource)读取配置文件,源包括 XML、注解等等,XML有可能来自本地或者网络。
从 ResourceLoader 加载到配置资源后,把配置转成(read) Definition 的形式
简单起见,我们可能还是要用回 XML 配置启动的方法(ClassPathXmlApplicationContext)来分析 (真香),不过其实内部大同小异。
1
|
public static void main(String[] args) {
|
1
|
public ClassPathXmlApplicationContext(String[] configLocations, boolean refresh, ApplicationContext parent)
|
refresh方法是启动的核心方法,执行了启动的所有操作,后面还会提到余下的部分
1
|
public void refresh() throws BeansException, IllegalStateException {
|
这个方法干了下面几件事
创建了 beanFactory (DefaultListableBeanFactory),并且把 beanFactory 赋值给 Context 保存
读取 Context 的配置,设置该工厂 是否允许 Bean 覆盖、是否允许循环引用 等
Context 读取加载 BeanDefinition,把 BeanDefinition 注册到 BeanFactory 的 Map 中
配置 DefinitionReader,读取 Resource
从XML读取配置树,转换成 Definition,触发监听事件
创建好之后的 beanFactory 的一部分的截图
主要是在 BeanFactory 里面注册实现了各种接口的Bean,Factory会为每一个特殊的接口类型维护一个列表,以后到达特定的位置,就会遍历这个列表。
比如 实现了 BeanPostProcessors 的接口的 Bean 有 A,B,C,那么到时候初始化 Bean 之前,就会遍历调用A,B,C的 postProcessBeforeInitialization方法,初始化 Bean 之后,就会调用 A,B,C 的postProcessAfterInitialization 方法,具体什么时候调用什么方法,请查看后面写的 Spring Bean 生命周期
1
|
|
Spring 默认 初始化的 Bean对象 都是单例的,采用的是单例注册表的方法。
我们重点关注单例如何实现,怎么解决循环引用
首先,初始化入口在 finishBeanFactoryInitialization(beanFactory)
,就是在 refresh() 方法的尾部。这个方法会进行马上初始化的 bean 进行马上初始化。
因为要兼容 延迟初始化(getBean时候加载) 和 马上初始化,所以最合适的方式就是把加载的逻辑写在 getBean 里边,需要马上加载的时候,提前调用 getBean 即可。
核心方法是 preInstantiateSinletons():
对符合条件的所有 beandefinition 里面 的 bean 执行了初始化操作:
1
|
public void preInstantiateSingletons() throws BeansException {
|
我去掉了部分无关紧要的代码,如果有兴趣可以去看原文件 AbstractBeanFactory
1
|
|
所以,getBean 就是 配套钩子 + 执行 createBean 方法
创建好的对象会放在 单例注册表 singletonObjects 中,下次再取的时候就从表里取,而不重新创建,从而实现单例模式。
如果单例还未创建,会在此创建 Bean
createBean 方法 主要做了些前置的工作,包括给 AOP 预留的拦截器 (AOP时,返回 Proxy 对象而不是真正的对象)
然后委托给 doCreateBean 方法,主要做了下面这些事:
实例化对象
装配属性
执行 InitializingBean 接口,BeanPostProcessor 接口钩子, init 方法钩子 (生命周期钩子)
我们主要关心一下怎么解决循环引用的问题:
1
|
<bean id="circleA" class="entity.CircleA" >
|
这样就构成了一个循环依赖,而我们默认是单例的,那如何一次性创建三个对象呢?
首先,在实例化对象的时候,先在 singletonFactories 注册一个工厂
1
|
addSingletonFactory(beanName, new ObjectFactory<Object>() {
|
circleA 属性注入时,到了 circleB ,会 getBean(circleB) ,然后又会 getBean(circleC)
getBean(circleC) 时,又看到了A ,会调用回 getBean(circleA),在getBean的时候,会调用getSingleton,他会先从工厂取,这个时候A已经在工厂列表了,然后用getObject,就可以拿到A的引用。
1
|
protected Object getSingleton(String beanName, boolean allowEarlyReference) {
|
这样就可以解决循环引用的问题
1
|
// 自定义事件
|
单例模式
观察者模式 (Listener)
Spring IOC 容器源码分析
Tiny-spring: A tiny IoC container refer to Spring.
Spring4参考手册中文版
Spring Framework Reference Documentation
Spring的扩展点
Spring Bean Life Cycle Tutorial
标签:bean 兼容 setter 获取 false work cap pid 仓库
原文地址:https://www.cnblogs.com/endv/p/11257617.html