(spring-第5回【IoC基础篇】)spring容器从加载配置文件到实例化bean的内部工作机制
2015-11-16 23:00
1166 查看
前面讲过,spring的生命周期为:实例化前奏-->实例化-->实例化后期-->初始化前期-->初始化-->初始化后期-->bean的具体调用-->销毁前-->销毁。那么,从装配XML属性到实例化bean的内部机制是怎样的,没有细说,今天我们来一起刨根问底。
还是老风格,以具体例子先入为主。下面是一个再简单不过的spring框架的栗子。(XML,有。Bean,有。Spring容器,有。main函数,有。麻雀虽小,但是够了。)
这是XML,简单易懂,嘎嘣脆:
这是Bean,要个子有个子,要西一翁有西一翁:
下面是启动函数,精悍!干练:
但是我要讲的重点是main函数跑起来后的日志:
一开始就加载了AbstractApplicationContext里的方法,那么这个方法做了什么?实际上,第一行是由AbstractApplicationContext的refresh()方法打印出的,容器一启动就要加载这个方法,让我们来揭开refresh()的面纱吧。
首先,这个AbstractApplicationContext必须是ClassPathXmlApplicationContext的父类,否则代码002的第5行怎么一跑起来会跑到AbstractApplicationContext里面的方法里去?孩子被打,当然是去叫爹咯。
在MyEclipse里,我们按住ctrl键,点击ClassPathXmlApplicationContext一路点下去你就发现其中的继承关系(姑且用—>表示子类指向被继承的父类):
ClassPathXmlApplicationContext —> AbstractXmlApplicationContext —>AbstractRefreshableConfigApplicationContext —>AbstractRefreshableApplicationContext—>AbstractApplicationContext。
我们进入AbstractApplicationContext,看到refresh()方法的庐山真面目:
人生若只如初见,看到这如此美丽的代码是否惊呆了天真烂漫的你?OK,我知道你英语没我好,我就大概讲一下这refresh()里面都干了些什么,这些步骤实际上就是实例化之前的一系列美丽动作:
第9行:准备bean factory (BeanFactory是spring框架的基础设施)
第16行:调用被注册为bean的BeanFactoryPostProcessors(工厂后处理器) (工厂后处理器负责对实例化之前未成形的bean进行加工处理)
第19行:注册BeanPostProcessors(Bean后处理器)来阻挡bean的创建。 (实例化后的bean需要用这个后处理器来进一步加工)
第22行:初始化消息源(国际化信息资源)。 (国际化很容易理解吧?比如微信可以切换中英文版本等等,后面会独列篇幅讲解)
第25行:初始化应用上下文事件广播器。 (spring有一套完善的事件发布和监听机制,事件广播器负责把事件通知给监听器,监听器来执行事件。后面会独列篇幅讲解)。
第28行:初始化其他特殊的bean。
第31行:检查是否有监听器然后注册监听器(监听器就跟bean一样,需要放在注册表中。后面会独列篇幅讲解)。
第34行:初始化所有单实例的bean(懒模式bean除外),单实例的bean初始化后把bean的引用放在spring容器的缓存中,调用者使用的是同一个额引用,任何一个调用者对bean的修改都会影响其他调用者。懒模式是指,spring容器启动时不会初始化,而在需要用到该bean时才初始化。XML<bean>标签中的lazy-init属性就是设置懒模式或者勤快模式的,false是勤快模式,true是懒模式。
第37行:创建上下文刷新事件,发布广播器。 (事件机制后面会独列篇幅讲解)
上面这些就是bean实例化前后的细枝末节了。那么上面的什么工厂后处理器,bean后处理器被调用后又是怎样处理的呢?
下面我们来细化一下创建一个完整的bean的作业流程:
整体是下面这样的:
简单点:
读取XML,转化并加工成BeanDefinition,实例化BeanDefinition。
具体点:
ResourceLoader加载XML配置信息后,由BeanDefinitionReader读取配置信息文件,把每个<bean>解析成BeanDefinition对象保存在注册表中。容器首先扫描注册表取出工厂后处理器,对注册表中的BeanDefinition进行加工处理。Spring容器接着从注册表中取出加工过的BeanDefinition开始着手bean实例化的事情。实例化时,首先由BeanWapper对bean进行封装,配置属性。最后利用注册表中的Bean后处理器装饰打扮,装配出一个准备就绪的Bean来。(注册表就类似于一个Map<K,V>,把所有的bean,不管是业务bean,还是spring自己的bean,都放到注册表里,用的时候取出来)。
再具体点:
ResourceLoader加载XML配置信息后,由BeanDefinitionReader读取配置信息文件,把每个<bean>解析成BeanDefinition对象保存在BeanDefinitionRegistry注册表中。这时的BeanDefinition可能只是个半成品,因为某些XML属性配置里会有占位符变量,这些变量此时不会被解析出来,需要继续优化,比如下面这样:
因为有1的情况出现,所以容器首先扫描注册表取出工厂后处理器,对注册表中的BeanDefinition进行加工处理,把占位符替换成真正的值,产生成品的BeanDefinition。
通过反射机制扫描BeanDefinitionRegistry所有属性编辑器的bean类,并把这些bean放到spring容器的属性编辑器注册表(PropertyEditorRegistry)中。(Spring的属性编辑器负责将配置文件中的文本配置值转换为Bean属性的配置值,这个后面会独辟章节来讲)。
Spring容器从BeanDefinitionRegistry中取出加工后的BeanDefinition,并调用InstantiationStrategy着手对bean的实例化工作。(这里的实例化只是相当于new了一个新对象一样,也就是说,只是跑一个构造函数,不会具体的为属性设置值,当然如果构造函数里写了设置值的语句,那么也可以赋值。比如一开始的那个例子,实例化时在构造函数里就给Car的name属性附上了"宝马"的名字)。
实例化的过程中,spring容器使用BeanWrapper对bean进行封装,BeanWrapper结合BeanDefinition和属性编辑器注册表中的属性编辑器完成bean的属性设置工作。
最后调用Bean后处理器对bean 作最后的润色。
话音到此戛然而止。洗洗睡吧。
知者不惑,仁者不忧,勇者不惧。
----子曰
还是老风格,以具体例子先入为主。下面是一个再简单不过的spring框架的栗子。(XML,有。Bean,有。Spring容器,有。main函数,有。麻雀虽小,但是够了。)
这是XML,简单易懂,嘎嘣脆:
。。。。。。 <bean id="car" class="com.mesopotamia.test1.Car" p:brand="宝马X5" p:maxSpeed="200"/> </beans>
这是Bean,要个子有个子,要西一翁有西一翁:
代码001 1 public class Car { private String name; private String brand; private double maxSpeed; public double getMaxSpeed() { return maxSpeed; } public void setMaxSpeed(double maxSpeed) { this.maxSpeed = maxSpeed; } private Log log=LogFactory.getLog(Car.class); public Car(){ name="宝马"; log.info("调用了Car的构造函数,实例化了Car,并把Car的name属性设为:"+name); } public String getName() { return name; } public void setName(String name) { this.name = name; } public String getBrand() { return brand; } public void setBrand(String brand) { this.brand = brand; } public String toString(){ return "名字"+name+" 型号"+" 速度:"+maxSpeed; } }
下面是启动函数,精悍!干练:
代码002 1 public class Main { private static Log log=LogFactory.getLog(Main.class); public static void main(String args[]){ ApplicationContext ctx = new ClassPathXmlApplicationContext("com/mesopotamia/test1/*.xml"); Car car1 = ctx.getBean("car",Car.class); log.info(car1.toString()); }
但是我要讲的重点是main函数跑起来后的日志:
代码003 1 2015-11-16 20:19:04,318 INFO [main] (AbstractApplicationContext.java:456) - Refreshing org.springframework.context.support.ClassPathXmlApplicationContext@1ff5ea7: startup date [Mon Nov 16 20:19:04 CST 2015]; root of context hierarchy 2015-11-16 20:19:04,371 INFO [main] (XmlBeanDefinitionReader.java:315) - Loading XML bean definitions from file [C:\MySoftware\workspace\springtest\WebRoot\WEB-INF\classes\com\mesopotamia\test1\beans.xml] 2015-11-16 20:19:04,482 INFO [main] (DefaultListableBeanFactory.java:555) - Pre-instantiating singletons in org.springframework.beans.factory.support.DefaultListableBeanFactory@6e293a: defining beans [car]; root of factory hierarchy 2015-11-16 20:19:04,483 INFO [main] (Car.java:22) - 调用了Car的构造函数,实例化了Car,并把Car的name属性设为:宝马 2015-11-16 20:19:04,533 INFO [main] (Main.java:15) - 名字宝马 型号 速度:200.0
一开始就加载了AbstractApplicationContext里的方法,那么这个方法做了什么?实际上,第一行是由AbstractApplicationContext的refresh()方法打印出的,容器一启动就要加载这个方法,让我们来揭开refresh()的面纱吧。
首先,这个AbstractApplicationContext必须是ClassPathXmlApplicationContext的父类,否则代码002的第5行怎么一跑起来会跑到AbstractApplicationContext里面的方法里去?孩子被打,当然是去叫爹咯。
在MyEclipse里,我们按住ctrl键,点击ClassPathXmlApplicationContext一路点下去你就发现其中的继承关系(姑且用—>表示子类指向被继承的父类):
ClassPathXmlApplicationContext —> AbstractXmlApplicationContext —>AbstractRefreshableConfigApplicationContext —>AbstractRefreshableApplicationContext—>AbstractApplicationContext。
我们进入AbstractApplicationContext,看到refresh()方法的庐山真面目:
public void refresh() throws BeansException, IllegalStateException { synchronized (this.startupShutdownMonitor) { // Prepare this context for refreshing. prepareRefresh(); // Tell the subclass to refresh the internal bean factory. ConfigurableListableBeanFactory beanFactory = obtainFreshBeanFactory(); // Prepare the bean factory for use in this context. prepareBeanFactory(beanFactory); try { // Allows post-processing of the bean factory in context subclasses. postProcessBeanFactory(beanFactory); // Invoke factory processors registered as beans in the context. invokeBeanFactoryPostProcessors(beanFactory); // Register bean processors that intercept bean creation. registerBeanPostProcessors(beanFactory); // Initialize message source for this context. initMessageSource(); // Initialize event multicaster for this context. initApplicationEventMulticaster(); // Initialize other special beans in specific context subclasses. onRefresh(); // Check for listener beans and register them. registerListeners(); // Instantiate all remaining (non-lazy-init) singletons. finishBeanFactoryInitialization(beanFactory); // Last step: publish corresponding event. finishRefresh(); } catch (BeansException ex) { // Destroy already created singletons to avoid dangling resources. destroyBeans(); // Reset 'active' flag. cancelRefresh(ex); // Propagate exception to caller. throw ex; } } }
人生若只如初见,看到这如此美丽的代码是否惊呆了天真烂漫的你?OK,我知道你英语没我好,我就大概讲一下这refresh()里面都干了些什么,这些步骤实际上就是实例化之前的一系列美丽动作:
第9行:准备bean factory (BeanFactory是spring框架的基础设施)
第16行:调用被注册为bean的BeanFactoryPostProcessors(工厂后处理器) (工厂后处理器负责对实例化之前未成形的bean进行加工处理)
第19行:注册BeanPostProcessors(Bean后处理器)来阻挡bean的创建。 (实例化后的bean需要用这个后处理器来进一步加工)
第22行:初始化消息源(国际化信息资源)。 (国际化很容易理解吧?比如微信可以切换中英文版本等等,后面会独列篇幅讲解)
第25行:初始化应用上下文事件广播器。 (spring有一套完善的事件发布和监听机制,事件广播器负责把事件通知给监听器,监听器来执行事件。后面会独列篇幅讲解)。
第28行:初始化其他特殊的bean。
第31行:检查是否有监听器然后注册监听器(监听器就跟bean一样,需要放在注册表中。后面会独列篇幅讲解)。
第34行:初始化所有单实例的bean(懒模式bean除外),单实例的bean初始化后把bean的引用放在spring容器的缓存中,调用者使用的是同一个额引用,任何一个调用者对bean的修改都会影响其他调用者。懒模式是指,spring容器启动时不会初始化,而在需要用到该bean时才初始化。XML<bean>标签中的lazy-init属性就是设置懒模式或者勤快模式的,false是勤快模式,true是懒模式。
第37行:创建上下文刷新事件,发布广播器。 (事件机制后面会独列篇幅讲解)
上面这些就是bean实例化前后的细枝末节了。那么上面的什么工厂后处理器,bean后处理器被调用后又是怎样处理的呢?
下面我们来细化一下创建一个完整的bean的作业流程:
整体是下面这样的:
简单点:
读取XML,转化并加工成BeanDefinition,实例化BeanDefinition。
具体点:
ResourceLoader加载XML配置信息后,由BeanDefinitionReader读取配置信息文件,把每个<bean>解析成BeanDefinition对象保存在注册表中。容器首先扫描注册表取出工厂后处理器,对注册表中的BeanDefinition进行加工处理。Spring容器接着从注册表中取出加工过的BeanDefinition开始着手bean实例化的事情。实例化时,首先由BeanWapper对bean进行封装,配置属性。最后利用注册表中的Bean后处理器装饰打扮,装配出一个准备就绪的Bean来。(注册表就类似于一个Map<K,V>,把所有的bean,不管是业务bean,还是spring自己的bean,都放到注册表里,用的时候取出来)。
再具体点:
ResourceLoader加载XML配置信息后,由BeanDefinitionReader读取配置信息文件,把每个<bean>解析成BeanDefinition对象保存在BeanDefinitionRegistry注册表中。这时的BeanDefinition可能只是个半成品,因为某些XML属性配置里会有占位符变量,这些变量此时不会被解析出来,需要继续优化,比如下面这样:
<bean id="simpleBean" class="com.spring.ch04.SimplePostProcessor"> <property name="connectionString" value="${simpleBean.connectionString}"/> <property name="password" value="${simpleBean.password}"/> <property name="username" value="${simpleBean.username}"/> </bean>
因为有1的情况出现,所以容器首先扫描注册表取出工厂后处理器,对注册表中的BeanDefinition进行加工处理,把占位符替换成真正的值,产生成品的BeanDefinition。
通过反射机制扫描BeanDefinitionRegistry所有属性编辑器的bean类,并把这些bean放到spring容器的属性编辑器注册表(PropertyEditorRegistry)中。(Spring的属性编辑器负责将配置文件中的文本配置值转换为Bean属性的配置值,这个后面会独辟章节来讲)。
Spring容器从BeanDefinitionRegistry中取出加工后的BeanDefinition,并调用InstantiationStrategy着手对bean的实例化工作。(这里的实例化只是相当于new了一个新对象一样,也就是说,只是跑一个构造函数,不会具体的为属性设置值,当然如果构造函数里写了设置值的语句,那么也可以赋值。比如一开始的那个例子,实例化时在构造函数里就给Car的name属性附上了"宝马"的名字)。
实例化的过程中,spring容器使用BeanWrapper对bean进行封装,BeanWrapper结合BeanDefinition和属性编辑器注册表中的属性编辑器完成bean的属性设置工作。
最后调用Bean后处理器对bean 作最后的润色。
话音到此戛然而止。洗洗睡吧。
知者不惑,仁者不忧,勇者不惧。
----子曰
相关文章推荐
- java实现冒泡算法
- Java基础学习总结——Java对象的序列化和反序列化
- Java用ArrayList实现栈
- Java日期与时间的处理/Date,String,Calendar转换
- Java锁的种类以及辨析(四):可重入锁
- 2._尚硅谷_佟刚_JavaWEB_Servlet-2
- Spring Learning
- Java笔记之String
- Java锁的种类以及辨析(三):阻塞锁
- Java锁的种类以及辨析(二):自旋锁的其他种类
- Java笔记之数组
- Java用ArrayList实现队列
- Java 计算日期加、减一天
- java锁的种类以及辨析(一):自旋锁
- java 中基本类型和字符串之间的相互转换
- electron(1)安装和使用
- 同样带来的是四道java笔试题
- 配置Java开发环境
- 夯实JAVA基本之一 —— 泛型详解(1):基本使用
- eclipse+maven搭建cxf webservice 完整例子