5.0:Spring-bean的加载
2014-04-21 15:55
423 查看
内容来自<Spring深度解析>,之后的不一一复述!
在Spring中,最基本的IOC容器接口是BeanFactory - 这个接口为具体的IOC容器的实现作了最基本的功能规定 - 不管怎么着,作为IOC容器,这些接口你必须要满足应用程序的最基本要求:
对bean加载的探索。bean加载的功能实现远比bean的解析要复杂得多, 对于加载bean的功能,在Spring中的调用方式为:
MyBean bean=(MyBean) bf.getBean("myBean")
这句代码实现了什么样的功能呢?我们可以先快速体验一下Spring中代码是如何实现的。
仅从代码量上就能看出来bean的加载经历了一个相当复杂的过程,其中涉及各种各样的考虑。相信读者细心阅读上面的代码,并参照部分代码注释,是可以粗略地了解整个Spring加载bean的过程。对于加载过程中所涉及的步骤大致如下。
(1)转换对应beanName。
或许很多人不理解转换对应beanName是什么意思,传入的参数name不就是beanName吗?其实不是,这里传入的参数可能是别名,也可能是FactoryBean,所以需要进行一系列的解析,这些解析内容包括如下内容。
去除FactoryBean的修饰符,也就是如果name="&aa",那么会首先去除&而使name="aa"。
取指定alias所表示的最终beanName,例如别名A指向名称为B的bean则返回B;若别名A指向别名B,别名B又指向名称为C的bean则返回C。
(2)尝试从缓存中加载单例。
单例在Spring的同一个容器内只会被创建一次,后续再获取bean,就直接从单例缓存中获取了。当然这里也只是尝试加载,首先尝试从缓存中加载,如果加载不成功则再次尝试从singletonFactories中加载。因为在创建单例bean的时候会存在依赖注入的情况,而在创建依赖的时候为了避免循环依赖,在Spring中创建bean的原则是不等bean创建完成就会将创建bean的ObjectFactory提早曝光加入到缓存中,一旦下一个bean创建时候需要依赖上一个bean则直接使用ObjectFactory(后面章节会对循环依赖重点讲解)。
(3)bean的实例化。
如果从缓存中得到了bean的原始状态,则需要对bean进行实例化。这里有必要强调一下,缓存中记录的只是最原始的bean状态,并不一定是我们最终想要的bean。举个例子,假如我们需要对工厂bean进行处理,那么这里得到的其实是工厂bean的初始状态,但是我们真正需要的是工厂bean中定义的factory-method方法中返回的bean,而getObjectForBeanInstance就是完成这个工作的,后续会详细讲解。
(4)原型模式的依赖检查。
只有在单例情况下才会尝试解决循环依赖,如果存在A中有B的属性,B中有A的属性,那么当依赖注入的时候,就会产生当A还未创建完的时候因为对于B的创建再次返回创建A,造成循环依赖,也就是情况:isPrototypeCurrentlyInCreation(beanName)判断true。
(5)检测parentBeanFactory。
从代码上看,如果缓存没有数据的话直接转到父类工厂上去加载了,这是为什么呢?
可能读者忽略了一个很重要的判断条件:parentBeanFactory != null && !containsBean Definition (beanName),parentBeanFactory != null。parentBeanFactory如果为空,则其他一切都是浮云,这个没什么说的,但是!containsBeanDefinition(beanName)就比较重要了,它是在检测如果当前加载的XML配置文件中不包含beanName所对应的配置,就只能到parentBeanFactory去尝试下了,然后再去递归的调用getBean方法。
(6)将存储XML配置文件的GernericBeanDefinition转换为RootBeanDefinition。
因为从XML配置文件中读取到的Bean信息是存储在GernericBeanDefinition中的,但是所有的Bean后续处理都是针对于RootBeanDefinition的,所以这里需要进行一个转换,转换的同时如果父类bean不为空的话,则会一并合并父类的属性。
(7)寻找依赖。
因为bean的初始化过程中很可能会用到某些属性,而某些属性很可能是动态配置的,并且配置成依赖于其他的bean,那么这个时候就有必要先加载依赖的bean,所以,在Spring的加载顺寻中,在初始化某一个bean的时候首先会初始化这个bean所对应的依赖。
(8)针对不同的scope进行bean的创建。
我们都知道,在Spring中存在着不同的scope,其中默认的是singleton,但是还有些其他的配置诸如prototype、request之类的。在这个步骤中,Spring会根据不同的配置进行不同的初始化策略。
(9)类型转换。
程序到这里返回bean后已经基本结束了,通常对该方法的调用参数requiredType是为空的,但是可能会存在这样的情况,返回的bean其实是个String,但是requiredType却传入Integer类型,那么这时候本步骤就会起作用了,它的功能是将返回的bean转换为requiredType所指定的类型。当然,String转换为Integer是最简单的一种转换,在Spring中提供了各种各样的转换器,用户也可以自己扩展转换器来满足需求。
经过上面的步骤后bean的加载就结束了,这个时候就可以返回我们所需要的bean了,图5-1直观地反映了整个过程。其中最重要的就是步骤(8),针对不同的scope进行bean的创建,你会看到各种常用的Spring特性在这里的实现。
在细化分析各个步骤提供的功能前,我们有必要先了解下FactoryBean的用法。
图5-1 bean的获取过程
在Spring中,最基本的IOC容器接口是BeanFactory - 这个接口为具体的IOC容器的实现作了最基本的功能规定 - 不管怎么着,作为IOC容器,这些接口你必须要满足应用程序的最基本要求:
对bean加载的探索。bean加载的功能实现远比bean的解析要复杂得多, 对于加载bean的功能,在Spring中的调用方式为:
MyBean bean=(MyBean) bf.getBean("myBean")
这句代码实现了什么样的功能呢?我们可以先快速体验一下Spring中代码是如何实现的。
public Object getBean(String name) throws BeansException { return doGetBean(name, null, null, false); }
@SuppressWarnings("unchecked") protected <T> T doGetBean(final String name, final Class<T> requiredType, final Object[] args, boolean typeCheckOnly) throws BeansException { // 提取对应的beanName final String beanName = transformedBeanName(name); Object bean; // Eagerly check singleton cache for manually registered singletons. /* * 检查缓存中或者实例工厂中是否有对应的实例 为什么首先会使用这段代码呢, 因为在创建单例bean的时候会存在依赖注入的情况,而在创建依赖的时候为了避免循环依赖, * Spring创建bean的原则是不等bean创建完成就会将创建bean的ObjectFactory提早曝光 * 也就是将ObjectFactory加入到缓存中,一旦下个bean创建时候需要依赖上个bean则直接使用Object Factory */ // 直接尝试从缓存获取或者singletonFactories中的ObjectFactory中获取 Object sharedInstance = getSingleton(beanName); if (sharedInstance != null && args == null) { if (logger.isDebugEnabled()) { if (isSingletonCurrentlyInCreation(beanName)) { logger.debug("Returning eagerly cached instance of singleton bean '" + beanName + "' that is not fully initialized yet - a consequence of a circular reference"); } else { logger.debug("Returning cached instance of singleton bean '" + beanName + "'"); } } // 返回对应的实例,有时候存在诸如BeanFactory的情况并不是直接返回实例本身而是返回指定方法返回的实例 bean = getObjectForBeanInstance(sharedInstance, name, beanName, null); } else { // Fail if we're already creating this bean instance: // We're assumably within a circular reference. // 只有在单例情况才会尝试解决循环依赖,原型模式情况下,如果存在 // A中有B的属性,B中有A的属性,那么当依赖注入的时候,就会产生当A还未创建完的时候因为 // 对于B的创建再次返回创建A,造成循环依赖,也就是下面的情况 if (isPrototypeCurrentlyInCreation(beanName)) { throw new BeanCurrentlyInCreationException(beanName); } // Check if bean definition exists in this factory. // 如果beanDefinitionMap中也就是在所有已经加载的类中不包括beanName则尝试从parentBeanFactory中检测 BeanFactory parentBeanFactory = getParentBeanFactory(); if (parentBeanFactory != null && !containsBeanDefinition(beanName)) { // Not found -> check parent. String nameToLookup = originalBeanName(name); // 递归到BeanFactory中寻找 if (args != null) { // Delegation to parent with explicit args. return (T) parentBeanFactory.getBean(nameToLookup, args); } else { // No args -> delegate to standard getBean method. return parentBeanFactory.getBean(nameToLookup, requiredType); } } // 如果不是仅仅做类型检查则是创建bean,这里要进行记录 if (!typeCheckOnly) { markBeanAsCreated(beanName); } try { // 将存储XML配置文件的GernericBeanDefinition转换为RootBeanDefinition,如果指定BeanName是子Bean的话同时会合并父类的相关属性 final RootBeanDefinition mbd = getMergedLocalBeanDefinition(beanName); checkMergedBeanDefinition(mbd, beanName, args); // Guarantee initialization of beans that the current bean depends on. String[] dependsOn = mbd.getDependsOn(); // 若存在依赖则需要递归实例化依赖的bean if (dependsOn != null) { for (String dependsOnBean : dependsOn) { if (isDependent(beanName, dependsOnBean)) { throw new BeanCreationException( "Circular depends-on relationship between '" + beanName + "' and '" + dependsOnBean + "'"); } // 缓存依赖调用 registerDependentBean(dependsOnBean, beanName); getBean(dependsOnBean); } } // 实例化依赖的bean后便可以实例化mbd本身了 // Create bean instance. if (mbd.isSingleton()) {// singleton模式的创建 sharedInstance = getSingleton(beanName, new ObjectFactory<Object>() { @Override public Object getObject() throws BeansException { try { return createBean(beanName, mbd, args); } catch (BeansException ex) { // Explicitly remove instance from singleton cache: It // might have been put there // eagerly by the creation process, to allow for circular // reference resolution. // Also remove any beans that received a temporary // reference to the bean. destroySingleton(beanName); throw ex; } } }); bean = getObjectForBeanInstance(sharedInstance, name, beanName, mbd); } else if (mbd.isPrototype()) { // prototype模式的创建(new) // It's a prototype -> create a new instance. Object prototypeInstance = null; try { beforePrototypeCreation(beanName); prototypeInstance = createBean(beanName, mbd, args); } finally { afterPrototypeCreation(beanName); } bean = getObjectForBeanInstance(prototypeInstance, name, beanName, mbd); } else {// 指定的scope上实例化bean String scopeName = mbd.getScope(); final Scope scope = this.scopes.get(scopeName); if (scope == null) { throw new IllegalStateException("No Scope registered for scope '" + scopeName + "'"); } try { Object scopedInstance = scope.get(beanName, new ObjectFactory<Object>() { @Override public Object getObject() throws BeansException { beforePrototypeCreation(beanName); try { return createBean(beanName, mbd, args); } finally { afterPrototypeCreation(beanName); } } }); bean = getObjectForBeanInstance(scopedInstance, name, beanName, mbd); } catch (IllegalStateException ex) { throw new BeanCreationException( beanName, "Scope '" + scopeName + "' is not active for the current thread; " + "consider defining a scoped proxy for this bean if you intend to refer to it from a singleton", ex); } } } catch (BeansException ex) { cleanupAfterBeanCreationFailure(beanName); throw ex; } } // Check if required type matches the type of the actual bean instance. // 检查需要的类型是否符合bean的实际类型 if (requiredType != null && bean != null && !requiredType.isAssignableFrom(bean.getClass())) { try { return getTypeConverter().convertIfNecessary(bean, requiredType); } catch (TypeMismatchException ex) { if (logger.isDebugEnabled()) { logger.debug( "Failed to convert bean '" + name + "' to required type [" + ClassUtils.getQualifiedName(requiredType) + "]", ex); } throw new BeanNotOfRequiredTypeException(name, requiredType, bean.getClass()); } } return (T) bean; }
仅从代码量上就能看出来bean的加载经历了一个相当复杂的过程,其中涉及各种各样的考虑。相信读者细心阅读上面的代码,并参照部分代码注释,是可以粗略地了解整个Spring加载bean的过程。对于加载过程中所涉及的步骤大致如下。
(1)转换对应beanName。
或许很多人不理解转换对应beanName是什么意思,传入的参数name不就是beanName吗?其实不是,这里传入的参数可能是别名,也可能是FactoryBean,所以需要进行一系列的解析,这些解析内容包括如下内容。
去除FactoryBean的修饰符,也就是如果name="&aa",那么会首先去除&而使name="aa"。
取指定alias所表示的最终beanName,例如别名A指向名称为B的bean则返回B;若别名A指向别名B,别名B又指向名称为C的bean则返回C。
(2)尝试从缓存中加载单例。
单例在Spring的同一个容器内只会被创建一次,后续再获取bean,就直接从单例缓存中获取了。当然这里也只是尝试加载,首先尝试从缓存中加载,如果加载不成功则再次尝试从singletonFactories中加载。因为在创建单例bean的时候会存在依赖注入的情况,而在创建依赖的时候为了避免循环依赖,在Spring中创建bean的原则是不等bean创建完成就会将创建bean的ObjectFactory提早曝光加入到缓存中,一旦下一个bean创建时候需要依赖上一个bean则直接使用ObjectFactory(后面章节会对循环依赖重点讲解)。
(3)bean的实例化。
如果从缓存中得到了bean的原始状态,则需要对bean进行实例化。这里有必要强调一下,缓存中记录的只是最原始的bean状态,并不一定是我们最终想要的bean。举个例子,假如我们需要对工厂bean进行处理,那么这里得到的其实是工厂bean的初始状态,但是我们真正需要的是工厂bean中定义的factory-method方法中返回的bean,而getObjectForBeanInstance就是完成这个工作的,后续会详细讲解。
(4)原型模式的依赖检查。
只有在单例情况下才会尝试解决循环依赖,如果存在A中有B的属性,B中有A的属性,那么当依赖注入的时候,就会产生当A还未创建完的时候因为对于B的创建再次返回创建A,造成循环依赖,也就是情况:isPrototypeCurrentlyInCreation(beanName)判断true。
(5)检测parentBeanFactory。
从代码上看,如果缓存没有数据的话直接转到父类工厂上去加载了,这是为什么呢?
可能读者忽略了一个很重要的判断条件:parentBeanFactory != null && !containsBean Definition (beanName),parentBeanFactory != null。parentBeanFactory如果为空,则其他一切都是浮云,这个没什么说的,但是!containsBeanDefinition(beanName)就比较重要了,它是在检测如果当前加载的XML配置文件中不包含beanName所对应的配置,就只能到parentBeanFactory去尝试下了,然后再去递归的调用getBean方法。
(6)将存储XML配置文件的GernericBeanDefinition转换为RootBeanDefinition。
因为从XML配置文件中读取到的Bean信息是存储在GernericBeanDefinition中的,但是所有的Bean后续处理都是针对于RootBeanDefinition的,所以这里需要进行一个转换,转换的同时如果父类bean不为空的话,则会一并合并父类的属性。
(7)寻找依赖。
因为bean的初始化过程中很可能会用到某些属性,而某些属性很可能是动态配置的,并且配置成依赖于其他的bean,那么这个时候就有必要先加载依赖的bean,所以,在Spring的加载顺寻中,在初始化某一个bean的时候首先会初始化这个bean所对应的依赖。
(8)针对不同的scope进行bean的创建。
我们都知道,在Spring中存在着不同的scope,其中默认的是singleton,但是还有些其他的配置诸如prototype、request之类的。在这个步骤中,Spring会根据不同的配置进行不同的初始化策略。
(9)类型转换。
程序到这里返回bean后已经基本结束了,通常对该方法的调用参数requiredType是为空的,但是可能会存在这样的情况,返回的bean其实是个String,但是requiredType却传入Integer类型,那么这时候本步骤就会起作用了,它的功能是将返回的bean转换为requiredType所指定的类型。当然,String转换为Integer是最简单的一种转换,在Spring中提供了各种各样的转换器,用户也可以自己扩展转换器来满足需求。
经过上面的步骤后bean的加载就结束了,这个时候就可以返回我们所需要的bean了,图5-1直观地反映了整个过程。其中最重要的就是步骤(8),针对不同的scope进行bean的创建,你会看到各种常用的Spring特性在这里的实现。
在细化分析各个步骤提供的功能前,我们有必要先了解下FactoryBean的用法。
图5-1 bean的获取过程
相关文章推荐
- Spring笔记04-Spring加载Bean
- Spring 5.0 bean的自动装配 02
- Spring源码之bean的加载(三)从bean中获取对象
- 【spring源码分析】加载bean过程(1)
- spring xmlbeanfactory加载活动图
- Spring源码阅读——Bean的加载和获取过程
- Spring_03_Bean 延迟加载
- spring在javaWeb环境中加载 bean 配置文件方式的选择
- spring加载bean实例化顺序
- Spring Bean加载过程(二)
- Spring SmartLifecycle 在容器所有bean加载和初始化完毕执行
- spring源码阅读之Bean的加载(二)
- mybatis的mapper文件错误,引申到spring无法加载bean
- Spring源码之bean的加载(四)获取单例
- Spring Bean加载顺序 Ordered接口简介
- 获取Spring加载的bean
- spring加载bean实例化顺序
- Spring加载一些配置文件中不存在的bean,如DB2,SYBASE,Derby,H2等等,Error while extracting database product name
- new类加载spring托管的bean
- Spring 动态加载bean