Spring的Bean的生命周期，Bean的装配和注入

微特尔普拉斯

已于 2023-02-26 01:42:30 修改

阅读量624

点赞数 1

分类专栏： Spring SpringBoot java 文章标签： java intellij-idea spring

于 2023-02-26 01:39:38 首次发布

本文链接：https://blog.csdn.net/waiter456/article/details/129222781

版权

java 同时被 3 个专栏收录

32 篇文章 0 订阅

订阅专栏

Spring

23 篇文章 1 订阅

订阅专栏

SpringBoot

18 篇文章 0 订阅

订阅专栏

文章详细介绍了Spring框架中Bean的作用域，包括singleton和prototype等，并通过示例展示了不同作用域下的行为差异。此外，文章还探讨了Bean的生命周期，从容器启动到销毁的过程，包括各种接口回调和初始化、销毁方法。最后，文章比较了XML配置与注解配置的优缺点。

摘要由CSDN通过智能技术生成

Spring容器启动获得BeanDefinition对象中有一个scope 属性。该属性控制着bean对象的作用域。本章节介绍Bean的作用域及生命周期，了解bean是怎么来的又怎么没的。

一、Bean的作用域
在Bean容器启动会读取bean的xml配置文件，然后将xml中每个bean元素分别转换成BeanDefinition对象。在BeanDefinition对象中有scope 属性，就是它控制着bean的作用域。
Spring框架支持5种作用域，有三种作用域是当开发者使用基于web的ApplicationContext的时候才生效的。下面就是Spring直接支持的作用域了，当然开发者也可以自己定制作用域。

作用域	描述
单例(singleton)	（默认）每一个Spring IoC容器都拥有唯一的一个实例对象
原型（prototype）	一个Bean定义，任意多个对象
请求（request）	一个HTTP请求会产生一个Bean对象，也就是说，每一个HTTP请求都有自己的Bean实例。只在基于web的Spring ApplicationContext中可用
会话（session）	限定一个Bean的作用域为HTTPsession的生命周期。同样，只有基于web的Spring ApplicationContext才能使用
全局会话（global session）	限定一个Bean的作用域为全局HTTPSession的生命周期。通常用于门户网站场景，同样，只有基于web的Spring ApplicationContext可用

我们可以以XMLInstance类为基础演示一下singleton和prototype作用域。
这里使用通过BeanFactory的getBean方法获取两次bean对象。

        XMLInstance instance=(XMLInstance)factory.getBean("xmlinstance");
        instance.setName("123");
        instance.Breath();
        instance=(XMLInstance)factory.getBean("xmlinstance");
        instance.Breath();

如果我们采用bean默认的作用域singleton，如下配置，则两个getbean获取的对象是一致的。

  <bean id="xmlinstance" class="com.demo.model.XMLInstance" scope="singleton">
      <property name="air" ref="CleanAir"></property>
      <property name="name" value="abc"></property>
  </bean>

输出结果:
Name:123;Air:CleanAir
Name:123;Air:CleanAir

如果我们采用bean默认的作用域prototype，如下配置，则两个getbean获取的对象是不一致的。

  <bean id="xmlinstance" class="com.demo.model.XMLInstance" scope="prototype">
      <property name="air" ref="CleanAir"></property>
      <property name="name" value="abc"></property>
  </bean>

输出结果:
Name:123;Air:CleanAir
Name:abc;Air:CleanAir

二、Bean的生命周期
前面章节介绍了bean容器以及bean的配置与注入，本章节学习bean的生命周期，了解bean是怎么来的又是怎么没的。

ApplicationContext容器中，Bean的生命周期流程如上图所示，流程大致如下：
1.首先容器启动后，会对scope为singleton且非懒加载的bean进行实例化，
2.按照Bean定义信息配置信息，注入所有的属性，
3.如果Bean实现了BeanNameAware接口，会回调该接口的setBeanName()方法，传入该Bean的id，此时该Bean就获得了自己在配置文件中的id，
4.如果Bean实现了BeanFactoryAware接口,会回调该接口的setBeanFactory()方法，传入该Bean的BeanFactory，这样该Bean就获得了自己所在的BeanFactory，
5.如果Bean实现了ApplicationContextAware接口,会回调该接口的setApplicationContext()方法，传入该Bean的ApplicationContext，这样该Bean就获得了自己所在的ApplicationContext，
6.如果有Bean实现了BeanPostProcessor接口，则会回调该接口的postProcessBeforeInitialzation()方法，
7.如果Bean实现了InitializingBean接口，则会回调该接口的afterPropertiesSet()方法，
8.如果Bean配置了init-method方法，则会执行init-method配置的方法，
9.如果有Bean实现了BeanPostProcessor接口，则会回调该接口的postProcessAfterInitialization()方法，
10.经过流程9之后，就可以正式使用该Bean了,对于scope为singleton的Bean,Spring的ioc容器中会缓存一份该bean的实例，而对于scope为prototype的Bean,每次被调用都会new一个新的对象，期生命周期就交给调用方管理了，不再是Spring容器进行管理了
11.容器关闭后，如果Bean实现了DisposableBean接口，则会回调该接口的destroy()方法，
12.如果Bean配置了destroy-method方法，则会执行destroy-method配置的方法，至此，整个Bean的生命周期结束。

这里在UserBean类基础上进行改造，增加了name属性并实现了ApplicationContextAware接口。

package com.demo.model;

import org.springframework.beans.BeansException;
import org.springframework.beans.factory.BeanFactory;
import org.springframework.beans.factory.BeanFactoryAware;
import org.springframework.beans.factory.BeanNameAware;
import org.springframework.beans.factory.DisposableBean;
import org.springframework.beans.factory.InitializingBean;
import org.springframework.context.ApplicationContext;
import org.springframework.context.ApplicationContextAware;

public class UserBean implements BeanNameAware,BeanFactoryAware,InitializingBean,DisposableBean,ApplicationContextAware {

    private String name;

    public String getName() {
        return name;
    }

    public void setName(String name) {
        this.name = name;
        System.out.println("set方法被调用");
    }

    public UserBean() {
         System.out.println("UserBean类构造方法");
    }
    
    public void setBeanName(String name) {
        System.out.println("BeanNameAware被调用");
    }

    public void setBeanFactory(BeanFactory beanFactory) throws BeansException {
        System.out.println("BeanFactoryAware被调用");    
    }

    public void afterPropertiesSet() throws Exception {
        System.out.println("InitializingBean被调用");    
    }

    public void destroy() throws Exception {
        System.out.println("DisposableBean被调用");
    }
    //自定义的初始化函数 
    public void myInit() { 
        System.out.println("myInit被调用");
    } 
    //自定义的销毁方法 
    public void myDestroy() {
        System.out.println("myDestroy被调用"); 
    }

    public void setApplicationContext(ApplicationContext applicationContext) throws BeansException {
        System.out.println("setApplicationContext被调用");
    }

}

定义了后置处理器CusBeanPostProcessor 实现了BeanPostProcessor 接口。

package com.demo.model;

import org.springframework.beans.BeansException;
import org.springframework.beans.factory.config.BeanPostProcessor;

public class CusBeanPostProcessor implements BeanPostProcessor {

    public Object postProcessBeforeInitialization(Object bean, String beanName) throws BeansException {
        System.out.println("postProcessBeforeInitialization被调用");
        return bean;
    }
    public Object postProcessAfterInitialization(Object bean, String beanName) throws BeansException {
        System.out.println("postProcessAfterInitialization被调用");
        return bean;
    }
}

在xml中配置bean和BeanPostProcessor。

  <bean id="user" class="com.demo.model.UserBean" destroy-method="myDestroy" init-method="myInit">
      <property name="name" value="abc"></property>
  </bean> 
  <bean id="postProcessor" class="com.demo.model.CusBeanPostProcessor" />

测试:

        ApplicationContext context=new ClassPathXmlApplicationContext(new String[]{"applicationContext.xml"});
        BeanFactory factory=context;
        UserBean user=(UserBean)context.getBean("user");
        ((ClassPathXmlApplicationContext)context).close();

输出结果:
UserBean类构造方法
set方法被调用
BeanNameAware被调用
BeanFactoryAware被调用
setApplicationContext被调用
postProcessBeforeInitialization被调用
InitializingBean被调用
myInit被调用
postProcessAfterInitialization被调用
DisposableBean被调用
myDestroy被调用

注解配置与xml配置的区别：
xml配置：书写灵活，修改方便，单修改xml时不需要修改源码，不用重新编译和部署。但维护起来相对麻烦。是一种集中式的的元数据，与源代码无绑定。
注解配置：写起来比较简单方便，配置、维护简单，但是修改很麻烦。是一种分散式的的元数据，与源代码紧绑定。
关于xml
xml优点：

1.使用xml配置可以让软件更具有扩展性；
比如，我们在spring中，我们不想使用接口而是想用接口的实现类，这个时候只需要修改xml配置中bean的class值就可以了。

2.对象之间的关系一目了然；

3.xml定义：可扩展标记语言，标准通用标记语言的子集，简称XML。从这个定义中我们可以发现，xml最大的优势就在于，开发者(程序员)能够为软件量身定做使用的标记，使得xml更通俗易懂；

4.成熟的校验机制，来保证正确。可以使用Schema或者是DTD来对xml的正确性进行校验。

5.基于xml配置的时候，只需要修改xml即可，不需要对现有的程序进行修改。

6.容易与其他系统进行数据交互。数据共享方便
xml的缺点

1.应用程序中如果使用了xml配置，需要解析xml的工具或者是是第三方类库的支持。

2.解析xml的时候必然会占用资源，势必会影响到应用程序的性能；以java为例，无论是将xml一次性装置到内存中，还是一行一行读取解析的，都会占用资源的。

3.在程序编译期间无法对其配置项的正确性进行验证，只能在运行期发现。

4.出错后，排错变得困难。往往在配置的时候，一个手误就会出现莫名其妙的错误。

5.开发的时候，既要维护代码又要维护配置文件，使得开发的效率降低。

6.代码与配置项之间有时候会存在很多“潜规则”.改变了任意一方，都有可能影响到另一方的使用。这是个大坑。比如：自定义的标记，如果其他开发不清楚这些的话，修改了无论是代码还是xml的配置，都会导致程序不能正常运行。

7.开发工具对xml的验证支持的不是很好。比如idea，对xml正确性，如果是自定义的，验证就不是很好。

关于注解
注解的优点
1.注解的解析可以不依赖于第三方库，可以之间使用Java自带的反射。

2.注解和代码在一起的，之间在类上，降低了维护两个地方的成本。

3.注解如果有问题，在编译期间，就可以验证正确性，如果出错更容易找。

4.使用注解开发能够提高开发效率。不用多个地方维护，不用考虑是否存在“潜规则”。

5.xml配置起来有时候冗长，此时注解可能是更好的选择，如jpa的实体映射；注解在处理一些不变的元数据时有时候比XML方便的多，比如springmvc的数据绑定，如果用xml写的代码会多的多；

6.注解最大的好处就是简化了XML配置；其实大部分注解一定确定后很少会改变，所以在一些中小项目中使用注解反而提供了开发效率，所以没必要一头走到黑；

7.注解相对于XML的另一个好处是类型安全的，XML只能在运行期才能发现问题。
注解的缺点
1.修改的话比较麻烦。如果需要对注解进行修改的话，就需要对整个项目重新编译。

2.处理业务类之间的复杂关系，不然xml那样容易修改，也不及xml那样明了。

3.在程序中注解太多的话，会影响代码质量，代码简洁会有影响。

4.如果后来的人对注解不了解，会给维护带来成本。

5.注解功能没有xml配置齐全。
总结
注解优点：简化配置，使用起来直观且容易，提升开发的效率，类型安全，容易检测出问题
缺点：修改起来比xml麻烦，如果不项目不了解，可能给开发和维护带来麻烦
Xml优点：把类与类之间松解偶；修改方便；容易扩展，容易和其他系统进行数据交互，对象之间的关系一目了然
缺点：配置冗长，需要额外维护；影响开发效率，类型不安全，校验不出来，出错不好排查

注解配置与xml配置都有各自的优缺点，没有那个是比对方更好的，只有在合适的地方选择合适的配置才是最优的。

三、Bean的管理操作——装配注入

bean管理指的是这两个操作：1.创建对象， 2.注入属性。

Bean装配注入的两种方式：

1.基于xml配置文件的方式实现， 2.基于注解方式实现。

（1）不同点： xml配置注入需要在spring的配置文件中添加bean及其相关属性，而使用注解注入可以实现自动装配，代码无需任何额外操作即可自动装配；（2）xml配置对于bean的依赖性更有优势，因为可以直接在配置文件中指定属性的依赖关系，而注解注入只能使用接口定义依赖；（3）xml配置提供更多的配置属性，允许您细化bean的更多特性，而注解只是简单地把bean装配在一起。使用XML配置的话，实现过程非常繁琐，不容易理解，同时配置文件较为凌乱，不便于查错和调试，同时必须依赖于XML文件，不能够进行代码编译。