IOC概念和SpringBean的生命周期

之前有写过SpringBean的文章,但是大部分都是搬运的,自己对它的深层次思想并没有掌握,所以在这里重写一下。

IOC部分在第一次学Spring的时候就已经在接触了,但是还是了解的不够深入,最近在看了一部分SpringIOC的源码之后,才模模糊糊的明白了一些,正好赶上组内技术分享,做此下文

1. WEB发展简史

老一辈的软件开发人员一般经历了从Model1到Model2,然后到后来的三层模型,最后到现在的Spring Boot。如果从Model1到Model2说起到我们现在使用的Spring Boot为整个时间轴的话,大致可以分为4个阶段:

  (1)初级阶段:使用Model1/Model2/三层模模型进行开发;

  (2)中级阶段:使用EJB进行分布式应用开发,忍受重量级框架带来的种种麻烦;

  (3)高级阶段:使用Spring春天带给我们的美好,但是还要忍受很多繁琐的配置;

  (4)骨灰级阶段:使用Spring Boot,畅享“预定大于配置”带给我们的种种乐趣!

1.1 Web发展初级阶段

 1、Model1开发模式:

  Model1的开发模式是:JSP+JavaBean的模式,它的核心是Jsp页面,在这个页面中,Jsp页面负责整合页面和JavaBean(业务逻辑),而且渲染页面,它的基本流程如下:

  img

  相信很多小伙伴在刚学习Web的时候,肯定使用到了Model1开发模式,也就是我们的业务代码、持久化代码直接写在Jsp页面里边,使用Jsp直接处理Web浏览器的请求,并使用JavaBean处理业务逻辑。

  利用我们现在熟悉的MVC模型的思想去看,虽然编写代码十分容易,但Jsp混淆了MVC模型中的视图层和控制层,高度耦合的结果是Jsp代码十分复杂,后期维护困难!

 2、Model2开发模式:

  Model1虽然在一定程度上解耦了,但JSP依旧即要负责页面控制,又要负责逻辑处理,职责不单一!此时Model2应运而生,使得各个部分各司其职,Model2是基于MVC模式的。

  Model2的开发模式是:Jsp+Servlet+JavaBean的模式,它和Model1不同的是,增加了Servlet,将调用页面数据,调用业务逻辑等工作放到了Servlet中处理,从而减轻了Jsp的工作负担!它的基本流程如下:

  

img

  Model2开发模式将Servlet的概念引入架构体系中,使用它来分配视图层Jsp的显示页面,同时调用模型层的JavaBean来控制业务逻辑。

 3、Model1和Model2的区别:

  Model1:简单,适合小型项目的开发,但是Jsp的职责过于繁重,职责分工不明确。在后期的维护工作中,必将为此付出代价!

  Model2:相对于Model1来说,职责分工更为明确,在Model1的基础上,抽取了Servlet层,体现了一个分层的思想,适合大型的项目开发!(当时的评判标准是适合大型项目开发的,现在看起来已经过时了!)

  Model2看起来已经尽善尽美了,尽管如此,他还不能称之为一个比较完善的MVC设计模式!

  4、Model1和Model2与三层的对比:

  在Model2中,我们将Servlet抽取出单独的一层,和Jsp协作完成用户数据交互的工作,也就是表示层。那么作为三层结构来说,又做了什么样的改进呢?三层则是在此基础上,将JavaBean再一次进行分割:业务逻辑、数据持久化,三层如下:

  (1)表示层,JSP/Servlet;

  (2)业务逻辑层:业务规则;

  (3)持久化层:主要包装持久化的逻辑 ;

  img

  各个的耦合性如下图:

  img

  Model1、Model2、三层是在解耦的基础上一步步进化而来,通过解耦我们可以进行进一步的抽象,以应对现实需求的变动。

1.2 Web发展初级阶段存在的问题

  经历过初级阶段的小伙伴肯定看得懂下边的一个项目结构,一个简单的MVC三层结构,使用JSP+Servlet+MySQL+JDBC技术,面向接口编程:

  

img

 1、面向接口编程的实例化对象

  以用户管理模块为例,有一个UserDao接口,有一个接口的实现类UserDaoImpl,如下:

  

img

  由于是面向接口编程,因此我们在每次使用UserDao的时候,都要进行实例化一次,实例化代码如下:

1
UserDao userDao = new UserDaoImpl();

  我们在每次使用UserDao的时候都需要进行实例化,当然不仅仅有UserDao需要进行实例化,还有很多需要进行实例化的,举例如下:

  

img

  可以看出,每一个方法中都需要进行实例化我们需要用到的接口的实现类,这就会存在大量的实例化对象,并且他们的生命周期可能就是从方法的调用开始到方法的调用结束为止,加大了GC回收的压力!

  2、使用单例模式的一次改进

  了解设计模式的可能会想到使用单例模式的方式来解决这个问题,以此来避免大量重复的创建对象,但是我们还要考虑到众多的这种对象的创建都需要改成单例模式的话,是一个耗时耗力的操作。

  对于这个系统来说,如果都把这种面向接口的对象实现类转换为单例模式的方式的话,大概也要写十几个或者上百个这种单例模式代码,而对于一个单例模式的写法来说,往往是模板式的代码,以静态内部类的方式实现代理模式如下:

  img

  可以看出,这种方式有两个问题:

  (1)业务代码与单例模式的模板代码放在一个类里,耦合性较高;

  (2)大量重复的单例模式的模板代码;

  从上述可以看出,使用的单例模式虽然从性能上有所提高,但是却加重了我们的开发成本。因此只会小规模的使用,例如我们操作JDBC的Utils对象等。

 3、我们开发中遇到的痛点

  从上述代码的演进过程我们可以看得出来,我们即需要一个单例的对象来避免系统中大量重复对象的创建和销毁,又不想因为使用单例模式造成大量重复无用的模板代码和代码的耦合!

  4、我们还能怎么做

  作为学院派的书生来说,我们可能会联想到“数据库连接池”,我们在获取数据库连接的时候会从这个池子中拿到一个连接的,假设这个数据库连接池很特殊,有且只能有N个数据库连接,并且每一个连接对象都不同(假设),那么这个不就相当于每一个连接都是单例的了吗?既可以避免大量对象的创建,也可以实现不会出现大量重复性的模板代码。

  因此,这里应该有一个大胆的想法,我们是否可以建立一个池子,将我们的接口实现类对象放入到这个池子中,我们在使用的时候直接从这个池子里边取就行了!

 5、这个池子

  如果我们要创建这个池子,首先要确定需要把哪些对象放进这个池子,通过怎样的方式放进去,放进去之后如何进行管理,如何进行获取,池子中的每一个对象的生命周期是怎么样的等等这些东西都是我们需要考虑到的!

​ 所以,Spring应运而生了!

2. IOC理论概念

2.1 背景

我们都知道,在采用面向对象方法设计的软件系统中,它的底层实现都是由N个对象组成的,所有的对象通过彼此的合作,最终实现系统的业务逻辑。

图1

如果我们打开机械式手表的后盖,就会看到与上面类似的情形,但是如果有一个齿轮出了问题,就可能会影响到整个齿轮组的正常运转。

齿轮组中齿轮之间的啮合关系,与软件系统中对象之间的耦合关系非常相似。对象之间的耦合关系是无法避免的,也是必要的,这是协同工作的基础。

为了解决对象之间的耦合度过高的问题,软件专家Michael Mattson提出了IOC理论,用来实现对象之间的“解耦”,目前这个理论已经被成功地应用到实践当中,很多的J2EE项目均采用了IOC框架产品Spring。


2.2 什么是控制反转(IOC)

IOC是Inversion of Control的缩写,多数书籍翻译成“控制反转”,还有些书籍翻译成为“控制反向”或者“控制倒置”。

观点大体是这样的:借助于“第三方”实现具有依赖关系的对象之间的解耦。

由于引进了中间位置的“第三方”,也就是IOC容器,使得A、B、C、D这4个对象没有了耦合关系,齿轮之间的传动全部依靠“第三方”了,全部对象的控制权全部上缴给“第三方”IOC容器,所以,IOC容器成了整个系统的关键核心,它起到了一种类似“粘合剂”的作用,把系统中的所有对象粘合在一起发挥作用,如果没有这个“粘合剂”,对象与对象之间会彼此失去联系,这就是有人把IOC容器比喻成“粘合剂”的由来。

拿掉IoC容器后的系统就是现在看到的画面,就是我们要实现整个系统所需要完成的全部内容。

这时候,A、B、C、D这4个对象之间已经没有了耦合关系,彼此毫无联系,这样的话,当你在实现A的时候,根本无须再去考虑B、C和D了,对象之间的依赖关系已经降低到了最低程度。

对比:

  • 引入IOC容器之前:

    如图1所示,对象A依赖于对象B,那么对象A在初始化或者运行到某一点的时候,自己必须主动去创建对象B或者使用已经创建的对象B。无论是创建还是使用对象B,控制权都在自己手上。

  • 引入IOC容器之后

    如图3所示,由于IOC容器的加入,对象A与对象B之间失去了直接联系,所以,当对象A运行到需要对象B的时候,IOC容器会主动创建一个对象B注入到对象A需要的地方。

通过前后的对比,我们不难看出来:对象A获得依赖对象B的过程,由主动行为变为了被动行为,控制权颠倒过来了,这就是“控制反转”这个名称的由来。


2.3 IOC的别名:依赖注入(DI)

既然IOC是控制反转,那么到底是“哪些方面的控制被反转了呢?”

“获得依赖对象的过程被反转了”

控制被反转之后,获得依赖对象的过程由自身管理变为了由IOC容器主动注入。

所谓依赖注入,就是由IOC容器在运行期间,动态地将某种依赖关系注入到对象之中。

所以,依赖注入(DI)和控制反转(IOC)是从不同的角度的描述的同一件事情,就是指通过引入IOC容器,利用依赖关系注入的方式,实现对象之间的解耦

收到任务:从外部USB设备读取一个文件。

电脑主机读取文件的时候,它一点也不会关心USB接口上连接的是什么外部设备,而且它确实也无须知道。它的任务就是读取USB接口,挂接的外部设备只要符合USB接口标准即可。所以,如果我给电脑主机连接上一个U盘,那么主机就从U盘上读取文件;如果我给电脑主机连接上一个外置硬盘,那么电脑主机就从外置硬盘上读取文件。挂接外部设备的权力由我作主,即控制权归我,至于USB接口挂接的是什么设备,电脑主机是决定不了,它只能被动的接受。电脑主机需要外部设备的时候,根本不用它告诉我,我就会主动帮它挂上它想要的外部设备,你看我的服务是多么的到位。这就是我们生活中常见的一个依赖注入的例子。在这个过程中,我就起到了IOC容器的作用

当电脑主机读取文件的时候,我就把它所要依赖的外部设备,帮他挂接上。整个外部设备注入的过程和一个被依赖的对象在系统运行时被注入另外一个对象内部的过程完全一样。

我们把依赖注入应用到软件系统中,再来描述一下这个过程:
对象A依赖于对象B,当对象 A需要用到对象B的时候,IOC容器就会立即创建一个对象B送给对象A。IOC容器就是一个对象制造工厂,你需要什么,它会给你送去,你直接使用就行了,而再也不用去关心你所用的东西是如何制成的,也不用关心最后是怎么被销毁的,这一切全部由IOC容器包办。

在传统的实现中,由程序内部代码来控制组件之间的关系。我们经常使用new关键字来实现两个组件之间关系的组合,这种实现方式会造成组件之间耦合。IOC很好地解决了该问题,它将实现组件间关系从程序内部提到外部容器,也就是说由容器在运行期将组件间的某种依赖关系动态注入组件中。


2.4 IOC带来的好处

  1. USB设备作为电脑主机的外部设备,在插入主机之前,与电脑主机没有任何的关系,只有被我们连接在一起之后,两者才发生联系,具有相关性。出问题了互不影响,便于调试,可维护性好。
  2. USB设备和电脑主机的之间无关性,还带来了另外一个好处,生产USB设备的厂商和生产电脑主机的厂商完全可以是互不相干的人,各干各事,他们之间唯一需要遵守的就是USB接口标准。每个开发团队的成员都只需要关心实现自身的业务逻辑,完全不用去关心其它的人工作进展,因为你的任务跟别人没有任何关系,你的任务可以单独测试,你的任务也不用依赖于别人的组件,再也不用扯不清责任了。
  3. 同一个USB外部设备可以插接到任何支持USB的设备。可复用性好
  4. 同USB外部设备一样,模块具有热插拔特性。IOC生成对象的方式转为外置方式,也就是把对象生成放在配置文件里进行定义,这样,当我们更换一个实现子类将会变得很简单,只要修改配置文件就可以了,完全具有热插拨的特性。

3. IOC容器的技术剖析

Spring 是一个“引擎”;

Spring MVC 是基于Spring的一个 MVC 框架 ;

Spring Boot 是基于Spring的条件注册的一套快速开发整合包。

IOC中最基本的技术就是“反射(Reflection)”编程,目前.Net C#、Java和PHP5等语言均支持,其中PHP5的技术书籍中,有时候也被翻译成“映射”。有关反射的概念和用法,大家应该都很清楚,通俗来讲就是根据给出的类名(字符串方式)来动态地生成对象

我们可以把IOC容器的工作模式看做是工厂模式的升华,可以把IOC容器看作是一个工厂,这个工厂里要生产的对象都在配置文件中给出定义,然后利用编程语言的的反射编程,根据配置文件中给出的类名生成相应的对象。从实现来看,IOC是把以前在工厂方法里写死的对象生成代码,改变为由配置文件来定义,也就是把工厂和对象生成这两者独立分隔开来,目的就是提高灵活性和可维护性。

先看下最基本的启动 Spring 容器的例子:

1
2
3
public static void main(String[] args) {
ApplicationContext context = new ClassPathXmlApplicationContext("classpath:applicationfile.xml");
}

ApplicationContext context = new ClassPathXmlApplicationContext(...) 其实很好理解,从名字上就可以猜出一二,就是在 ClassPath 中寻找 xml 配置文件,根据 xml 文件内容来构建 ApplicationContext。当然,除了 ClassPathXmlApplicationContext 以外,我们也还有其他构建 ApplicationContext 的方案可供选择,我们先来看看大体的继承结构是怎么样的:

我们可以看到,ClassPathXmlApplicationContext 兜兜转转了好久才到 ApplicationContext 接口,同样的,我们也可以使用绿颜色的 FileSystemXmlApplicationContextAnnotationConfigApplicationContext 这两个类。

FileSystemXmlApplicationContext 的构造函数需要一个 xml 配置文件在系统中的路径,其他和 ClassPathXmlApplicationContext 基本上一样。

AnnotationConfigApplicationContext 是基于注解来使用的,它不需要配置文件,采用 java 配置类和各种注解来配置,是比较简单的方式,也是大势所趋吧。

不过今天旨在帮助大家理解整个构建流程,所以决定使用 ClassPathXmlApplicationContext 进行分析。

定义接口实现类:

1
2
3
4
5
public class MessageServiceImpl implements MessageService {
public String getMessage() {
return "hello world";
}
}

接下来,我们在 resources 目录新建一个配置文件,文件名随意,通常叫 application.xml 或 application-xxx.xml 就可以了:

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

<bean id="messageService" class="com.javadoop.example.MessageServiceImpl"/>
</beans>

这样,我们就可以跑起来了:

1
2
3
4
5
6
7
8
9
10
11
12
13
public class App {
public static void main(String[] args) {
// 用我们的配置文件来启动一个 ApplicationContext
ApplicationContext context = new ClassPathXmlApplicationContext("classpath:application.xml");

System.out.println("context 启动成功");

// 从 context 中取出我们的 Bean,而不是用 new MessageServiceImpl() 这种方式
MessageService messageService = context.getBean(MessageService.class);
// 这句将输出: hello world
System.out.println(messageService.getMessage());
}
}

以上例子很简单,不过也够引出本文的主题了,就是怎么样通过配置文件来启动 Spring 的 ApplicationContext?也就是我们今天要分析的 IOC 的核心了。ApplicationContext 启动过程中,会负责创建实例 Bean,往各个 Bean 中注入依赖等。

3.1BeanFactory 简介

BeanFactory,从名字上也很好理解,生产 bean 的工厂,它负责生产和管理各个 bean 实例。

初学者可别以为我之前说那么多和 BeanFactory 无关,前面说的 ApplicationContext 其实就是一个 BeanFactory。我们来看下和 BeanFactory 接口相关的主要的继承结构:

2

我想,大家看完这个图以后,可能就不是很开心了。ApplicationContext 往下的继承结构前面一张图说过了,这里就不重复了。

  1. ApplicationContext 继承了 ListableBeanFactory,这个 Listable 的意思就是,通过这个接口,我们可以获取多个 Bean。
  2. ApplicationContext 继承了 HierarchicalBeanFactory,Hierarchical 单词本身已经能说明问题了,也就是说我们可以在应用中起多个 BeanFactory,然后可以将各个 BeanFactory 设置为父子关系。
  3. AutowireCapableBeanFactory 这个名字中的 Autowire 大家都非常熟悉,它就是用来自动装配 Bean 用的,但是仔细看上图,ApplicationContext 并没有继承它,不过不用担心,不使用继承,不代表不可以使用组合,如果你看到 ApplicationContext 接口定义中的最后一个方法 getAutowireCapableBeanFactory() 就知道了。
  4. ConfigurableListableBeanFactory 也是一个特殊的接口,看图,特殊之处在于它继承了第二层所有的三个接口,而 ApplicationContext 没有。

3.2 SpringBean的生命周期

Spring Bean的完整生命周期从创建Spring容器开始,直到最终Spring容器销毁Bean,这其中包含了一系列关键点。

img

img

3.3接口分类

Bean的完整生命周期经历了各种方法调用,这些方法可以划分为以下几类:

  1. Bean自身的方法:这个包括了Bean本身调用的方法和通过配置文件中的init-method和destroy-method指定的方法
  2. Bean级生命周期接口方法:这个包括了BeanNameAware、BeanFactoryAware、InitializingBean和DiposableBean这些接口的方法
  3. 容器级生命周期接口方法:这个包括了InstantiationAwareBeanPostProcessor 和 BeanPostProcessor 这两个接口实现,一般称它们的实现类为“后处理器”。
  4. 工厂后处理器接口方法:这个包括了AspectJWeavingEnabler, ConfigurationClassPostProcessor, CustomAutowireConfigurer等等非常有用的工厂后处理器  接口的方法。工厂后处理器也是容器级的。在应用上下文装配配置文件之后立即调用。

3.4 演示

先来看看,Spring在Bean从创建到销毁的生命周期中可能做得事情。

详细代码在文章底部附录

3.4.1 实现*Aware接口 在Bean中使用Spring框架的一些对象

有些时候我们需要在Bean的初始化中使用Spring框架自身的一些对象来执行一些操作,比如获取ServletContext的一些参数,获取ApplicaitionContext中的BeanDefinition的名字,获取Bean在容器中的名字等等。为了让Bean可以获取到框架自身的一些对象,Spring提供了一组名为Aware的接口。
这些接口均继承于org.springframework.beans.factory.Aware标记接口,并提供一个将由Bean实现的set
方法,Spring通过基于setter的依赖注入方式使相应的对象可以被Bean使用。

网上说,这些接口是利用观察者模式实现的,因为时间有限,所以我暂时还不太明白,有兴趣的话大家可以去详细的看一下。

重要的Aware接口:

  • ApplicationContextAware: 获得ApplicationContext对象,可以用来获取所有Bean definition的名字。
  • BeanFactoryAware:获得BeanFactory对象,可以用来检测Bean的作用域。
  • BeanNameAware:获得Bean在配置文件中定义的名字。
  • ResourceLoaderAware:获得ResourceLoader对象,可以获得classpath中某个文件。
  • ServletContextAware:在一个MVC应用中可以获取ServletContext对象,可以读取context中的参数。
  • ServletConfigAware在一个MVC应用中可以获取ServletConfig对象,可以读取config中的参数。

3.4.2 BeanPostProcessor

上面的*Aware接口是针对某个实现这些接口的Bean定制初始化的过程,
Spring同样可以针对容器中的所有Bean,或者某些Bean定制初始化过程,只需提供一个实现BeanPostProcessor接口的类即可。 该接口中包含两个方法,postProcessBeforeInitialization和postProcessAfterInitialization。 postProcessBeforeInitialization方法会在容器中的Bean初始化之前执行, postProcessAfterInitialization方法在容器中的Bean初始化之后执行。

3.5 总结

所以。。。结合第一节控制台输出的内容,Spring Bean的生命周期是这样纸的:

  • Bean容器找到配置文件中Spring Bean的定义。
  • Bean容器利用Java Reflection API创建一个Bean的实例。
  • 如果涉及到一些属性值 利用set方法设置一些属性值。
  • 如果Bean实现了BeanNameAware接口,调用setBeanName()方法,传入Bean的名字。
  • 如果Bean实现了BeanClassLoaderAware接口,调用setBeanClassLoader()方法,传入ClassLoader对象的实例。
  • 如果Bean实现了BeanFactoryAware接口,调用setBeanClassLoader()方法,传入ClassLoader对象的实例。
  • 与上面的类似,如果实现了其他*Aware接口,就调用相应的方法。
  • 如果有和加载这个Bean的Spring容器相关的BeanPostProcessor对象,执行postProcessBeforeInitialization()方法
  • 如果Bean实现了InitializingBean接口,执行afterPropertiesSet()方法。
  • 如果Bean在配置文件中的定义包含init-method属性,执行指定的方法。
  • 如果有和加载这个Bean的Spring容器相关的BeanPostProcessor对象,执行postProcessAfterInitialization()方法
  • 当要销毁Bean的时候,如果Bean实现了DisposableBean接口,执行destroy()方法。
  • 当要销毁Bean的时候,如果Bean在配置文件中的定义包含destroy-method属性,执行指定的方法。

Spring BeanLifeCycle

参考

这篇文章参考了大量的博客,一一列举如下:

附录

演示部分的代码如下:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
package com.myhexin.ioc.bean;

import org.springframework.beans.BeansException;
import org.springframework.beans.factory.*;
import org.springframework.boot.context.properties.ConfigurationProperties;
import org.springframework.stereotype.Component;

// 实现InitializingBean和DisposableBean接口
public class Person1 implements BeanFactoryAware, BeanNameAware, InitializingBean, DisposableBean {

private String name;
private String address;
private int phone;

private BeanFactory beanFactory;
private String beanName;

public Person1() {
System.out.println("【构造器】调用Person1的构造器实例化");
}

public String getName() {
return name;
}

public void setName(String name) {
System.out.println("【注入属性】注入属性name");
this.name = name;
}

public String getAddress() {
return address;
}

public void setAddress(String address) {
System.out.println("【注入属性】注入属性address");
this.address = address;
}

public int getPhone() {
return phone;
}

public void setPhone(int phone) {
System.out.println("【注入属性】注入属性phone");
this.phone = phone;
}

//为一个bean设置属性,除了上面的通过setter注入的方式还有哪几种?

@Override
public String toString() {
return "Person{" +
"name='" + name + '\'' +
", address='" + address + '\'' +
", phone=" + phone +
'}';
}

// 这种方法比较简单,但是不建议使用。因为这样会将Bean的实现和Spring框架耦合在一起。
@Override
public void destroy() throws Exception {
System.out.println("执行DisposableBean接口的destroy方法");
}
@Override
public void afterPropertiesSet() throws Exception {
System.out.println("执行InitializingBean接口的afterPropertiesSet方法");
}


@Override
public void setBeanFactory(BeanFactory beanFactory) throws BeansException {
System.out.println("【BeanFactoryAware接口】调用BeanFactoryAware.setBeanFactory()");
this.beanFactory = beanFactory;
}

@Override
public void setBeanName(String s) {
System.out.println("【BeanNameAware接口】调用BeanNameAware.setBeanName()");
this.beanName = name;
}

//自定义的初始化函数
public void myInit() {
System.out.println("myInit被调用");
}

//自定义的销毁方法
public void myDestroy() {
System.out.println("myDestroy被调用");
}

}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
package com.myhexin.ioc.bean;

import org.springframework.stereotype.Component;

import javax.annotation.PostConstruct;
import javax.annotation.PreDestroy;

//使用@PostConstruct和@PreDestroy注解
//@Component
public class Person2{

public Person2() {
System.out.println("【构造器】调用Person2的构造器实例化");
}

@PostConstruct
public void initPostConstruct(){
System.out.println("执行PostConstruct注解标注的方法,初始化bean");
}

@PreDestroy
public void preDestroy(){
System.out.println("执行preDestroy注解标注的方法,销毁bean");
}
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
package com.myhexin.ioc.bean;

import org.springframework.beans.BeansException;
import org.springframework.beans.factory.config.BeanDefinition;
import org.springframework.beans.factory.config.BeanFactoryPostProcessor;
import org.springframework.beans.factory.config.ConfigurableListableBeanFactory;

public class PersonBeanFactoryPostProcessor implements BeanFactoryPostProcessor {
@Override
public void postProcessBeanFactory(ConfigurableListableBeanFactory configurableListableBeanFactory) throws BeansException {
System.out.println("BeanFactoryPostProcessor调用postProcessBeanFactory方法");
BeanDefinition bd = configurableListableBeanFactory.getBeanDefinition("person1");
bd.getPropertyValues().addPropertyValue("phone", "110");
}
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
package com.myhexin.ioc.bean;

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

public class PersonBeanPostProcessor implements BeanPostProcessor {

@Override
public Object postProcessBeforeInitialization(Object bean, String beanName) throws BeansException {
System.out.println("BeanPostProcessor接口方法postProcessBeforeInitialization对属性进行更改!");
return bean;
}
@Override
public Object postProcessAfterInitialization(Object bean, String beanName) throws BeansException {
System.out.println("BeanPostProcessor接口方法postProcessAfterInitialization对属性进行更改!");
return bean;
}
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
package com.myhexin.ioc;

import com.myhexin.ioc.bean.Person1;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.context.ApplicationContext;
import org.springframework.context.support.ClassPathXmlApplicationContext;

public class IocApplication {
public static void main(String[] args) {
System.out.println("开始初始化容器");
ApplicationContext ac = new ClassPathXmlApplicationContext("classpath:bean.xml");

System.out.println("xml加载完毕");
Person1 person1 = (Person1) ac.getBean("person1");
System.out.println(person1);
System.out.println("关闭容器");
((ClassPathXmlApplicationContext)ac).close();
}
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:p="http://www.springframework.org/schema/p"
xsi:schemaLocation="
http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans-3.2.xsd">

<bean id="person1" destroy-method="myDestroy"
init-method="myInit" class="com.myhexin.ioc.bean.Person1">
<property name="name">
<value>巫妖王</value>
</property>
<property name="address">
<value>东北</value>
</property>
<!--<property name="phone">-->
<!--<value>888</value>-->
<!--</property>-->
</bean>

<!-- 配置自定义的后置处理器 -->
<bean id="personBeanPostProcessor" class="com.myhexin.ioc.bean.PersonBeanPostProcessor" />

<bean id="personBeanFactoryPostProcessor" class="com.myhexin.ioc.bean.PersonBeanFactoryPostProcessor" />
</beans>
0%