关于spring:spring源码解析springcore二

Bean解析

XmlBeanDefinitionReader.registerBeanDefinitions:

public int registerBeanDefinitions(Document doc, Resource resource) {

BeanDefinitionDocumentReader documentReader = createBeanDefinitionDocumentReader();

int countBefore = getRegistry().getBeanDefinitionCount();

documentReader.registerBeanDefinitions(doc, createReaderContext(resource));

return getRegistry().getBeanDefinitionCount() - countBefore;

}

createBeanDefinitionDocumentReader:

protected BeanDefinitionDocumentReader createBeanDefinitionDocumentReader() {

return BeanDefinitionDocumentReader.class.cast

//反射

(BeanUtils.instantiateClass(this.documentReaderClass));

}

documentReaderClass默认是DefaultBeanDefinitionDocumentReader，这其实也是策略模式，通过setter办法能够更换其实现。

留神cast办法，代替了强转。

createReaderContext：

public XmlReaderContext createReaderContext(Resource resource) {

return new XmlReaderContext(resource, this.problemReporter, this.eventListener,

this.sourceExtractor, this, getNamespaceHandlerResolver());

}

problemReporter是一个FailFastProblemReporter对象。

eventListener是EmptyReaderEventListener对象，此类里的办法都是空实现。

sourceExtractor是NullSourceExtractor对象，间接返回空，也是空实现。

getNamespaceHandlerResolver默认返回DefaultNamespaceHandlerResolver对象，用来获取xsd对应的处理器。

XmlReaderContext的作用感觉就是这一堆参数的容器，糅合到一起传给DocumentReader，并美其名为Context。能够看出，Spring中到处都是策略模式，大量操作被形象成接口。

DefaultBeanDefinitionDocumentReader.registerBeanDefinitions:

@Overridepublic void registerBeanDefinitions(Document doc, XmlReaderContext readerContext) {

this.readerContext = readerContext;

Element root = doc.getDocumentElement();

doRegisterBeanDefinitions(root);

}

doRegisterBeanDefinitions:

protected void doRegisterBeanDefinitions(Element root) {

BeanDefinitionParserDelegate parent = this.delegate;

this.delegate = createDelegate(getReaderContext(), root, parent);

//默认的命名空间即

//http://www.springframework.org/schema/beans

if (this.delegate.isDefaultNamespace(root)) {

//查看profile属性

String profileSpec = root.getAttribute(PROFILE_ATTRIBUTE);

if (StringUtils.hasText(profileSpec)) {

//profile属性能够以,宰割

String[] specifiedProfiles = StringUtils.tokenizeToStringArray(

profileSpec, BeanDefinitionParserDelegate.MULTI_VALUE_ATTRIBUTE_DELIMITERS);

if (!getReaderContext().getEnvironment().acceptsProfiles(specifiedProfiles)) {

return;

}

preProcessXml(root);

parseBeanDefinitions(root, this.delegate);

postProcessXml(root);

this.delegate = parent;

}

delegate的作用在于解决beans标签的嵌套，其实Spring配置文件是能够写成这样的:

<?xml version="1.0" encoding="UTF-8"?>

<beans>

<beans>

</beans>

从图中能够大概猜出这个解决xml中的Elements/beans标签的嵌套

xml(schema)的命名空间其实相似于java的报名，命名空间采纳URL，比方Spring的是这样:

<?xml version="1.0" encoding="UTF-8"?>

xmlns属性就是xml标准定义的用来设置命名空间的。这样设置了之后其实外面的bean元素全名就相当于http://www.springframework.org/schema/beans:bean，能够无效的避免命名抵触。命名空间能够通过标准定义的org.w3c.dom.Node.getNamespaceURI办法取得。

留神一下profile的查看, AbstractEnvironment.acceptsProfiles:

@Overridepublic boolean acceptsProfiles(String... profiles) {

Assert.notEmpty(profiles, "Must specify at least one profile");

for (String profile : profiles) {

if (StringUtils.hasLength(profile) && profile.charAt(0) == '!') {

if (!isProfileActive(profile.substring(1))) {

return true;

}

} else if (isProfileActive(profile)) {

return true;

}

return false;

}

原理很简略，留神从源码能够看出，profile属性反对!取反。

preProcessXml办法是个空实现，供子类去笼罩，目标在于给子类一个把咱们自定义的标签转为Spring规范标签的机会, 想的真周到。

DefaultBeanDefinitionDocumentReader.parseBeanDefinitions：

protected void parseBeanDefinitions(Element root, BeanDefinitionParserDelegate delegate) {

if (delegate.isDefaultNamespace(root)) {

NodeList nl = root.getChildNodes();

for (int i = 0; i < nl.getLength(); i++) {

Node node = nl.item(i);

if (node instanceof Element) {

Element ele = (Element) node;

if (delegate.isDefaultNamespace(ele)) {

parseDefaultElement(ele, delegate);

} else {

delegate.parseCustomElement(ele);

}

} else {

delegate.parseCustomElement(root);

}

可见，对于非默认命名空间的元素交由delegate解决。

默认命名空间解析

即import, alias, bean, 嵌套的beans四种元素。parseDefaultElement:

private void parseDefaultElement(Element ele, BeanDefinitionParserDelegate delegate) {

//"import"

if (delegate.nodeNameEquals(ele, IMPORT_ELEMENT)) {

importBeanDefinitionResource(ele);

}

//"alias"

else if (delegate.nodeNameEquals(ele, ALIAS_ELEMENT)) {

processAliasRegistration(ele);

}

//"bean"

else if (delegate.nodeNameEquals(ele, BEAN_ELEMENT)) {

processBeanDefinition(ele, delegate);

}

//"beans"

else if (delegate.nodeNameEquals(ele, NESTED_BEANS_ELEMENT)) {

// recurse

doRegisterBeanDefinitions(ele);

}

import

写法示例:

importBeanDefinitionResource套路和之前的配置文件加载齐全一样，不过留神被import进来的文件是先于以后文件被解析的。

alias

退出有一个bean名为componentA-dataSource，然而另一个组件想以componentB-dataSource的名字应用，就能够这样定义:

processAliasRegistration外围源码:

protected void processAliasRegistration(Element ele) {

String name = ele.getAttribute(NAME_ATTRIBUTE);//NAME_ATTRIBUTE=="name"

String alias = ele.getAttribute(ALIAS_ATTRIBUTE);//ALIAS_ATTRIBUTE ="alias"

getReaderContext().getRegistry().registerAlias(name, alias);

getReaderContext().fireAliasRegistered(name, alias, extractSource(ele));

}

4.2.2的局部代码

从后面的源码能够发现，registry其实就是DefaultListableBeanFactory，它实现了BeanDefinitionRegistry接口(这里我用下面的图片证实更确信)。registerAlias办法的实现在_SimpleAliasRegistry_:

@Overridepublic void registerAlias(String name, String alias) {

Assert.hasText(name, "'name' must not be empty");

Assert.hasText(alias, "'alias' must not be empty");

//名字和别名一样

if (alias.equals(name)) {

//ConcurrentHashMap

this.aliasMap.remove(alias);

} else {

String registeredName = this.aliasMap.get(alias);

if (registeredName != null) {

if (registeredName.equals(name)) {

// An existing alias - no need to re-register

return;

}

if (!allowAliasOverriding()) {

throw new IllegalStateException

("Cannot register alias '" + alias + "' for name '" +

name + "': It is already registered for name '" + registeredName + "'.");

}

checkForAliasCircle(name, alias);

this.aliasMap.put(alias, name);

}

所以别名关系的保留应用Map实现，key为别名，value为原本的名字。

bean

bean节点是Spring最最常见的节点了。

DefaultBeanDefinitionDocumentReader.processBeanDefinition:

protected void processBeanDefinition(Element ele, BeanDefinitionParserDelegate delegate) {

BeanDefinitionHolder bdHolder = delegate.parseBeanDefinitionElement(ele);

if (bdHolder != null) {

bdHolder = delegate.decorateBeanDefinitionIfRequired(ele, bdHolder);

try {

// Register the final decorated instance.

BeanDefinitionReaderUtils.registerBeanDefinition(bdHolder, getReaderContext().getRegistry());

}catch (BeanDefinitionStoreException ex) {

getReaderContext().error("Failed to register bean definition with name '" +

bdHolder.getBeanName() + "'", ele, ex);

}

// Send registration event.

getReaderContext().fireComponentRegistered(new BeanComponentDefinition(bdHolder));

}

id & name解决

最终调用BeanDefinitionParserDelegate.parseBeanDefinitionElement(Element ele, BeanDefinition containingBean)，源码较长，分局部阐明。

首先获取到id和name属性，name属性反对配置多个，以逗号（或分号）分隔，如果没有指定id，那么将以第一个name属性值代替。id必须是惟一的，name属性其实是alias的角色，能够和其它的bean反复，如果name也没有配置，那么其实什么也没做。（如图所示把重点指出了）

beanName生成

如果name和id属性都没有指定，那么Spring会本人生成一个, BeanDefinitionParserDelegate.parseBeanDefinitionElement:

beanName = this.readerContext.generateBeanName(beanDefinition);

String beanClassName = beanDefinition.getBeanClassName();

aliases.add(beanClassName);//generateBeanName最终调用的办法

4.2.2版本如下，略微有些区别，就是这个生成的beanName是BeanDefinitionReaderUtils的工具类生成的，两个版本最终调用的都还是BeanDefinitionReaderUtils.generateBeanName:

可见，Spring同时会把类名作为其别名。

最终调用的是BeanDefinitionReaderUtils.generateBeanName:

public static String generateBeanName(

BeanDefinition definition, BeanDefinitionRegistry registry, boolean isInnerBean) {

String generatedBeanName = definition.getBeanClassName();

if (generatedBeanName == null) {

if (definition.getParentName() != null) {

generatedBeanName = definition.getParentName() + "$child";

//工厂办法产生的bean

} else if (definition.getFactoryBeanName() != null) {

generatedBeanName = definition.getFactoryBeanName() + "$created";

}

String id = generatedBeanName;

if (isInnerBean) {

// Inner bean: generate identity hashcode suffix.

id = generatedBeanName + GENERATED_BEAN_NAME_SEPARATOR +

ObjectUtils.getIdentityHexString(definition);

} else {

// Top-level bean: use plain class name.

// Increase counter until the id is unique.

int counter = -1;

//用类名#自增的数字命名

while (counter == -1 || registry.containsBeanDefinition(id)) {

counter++;

id = generatedBeanName + GENERATED_BEAN_NAME_SEPARATOR + counter;

}

return id;

}

bean解析

还是分局部阐明(parseBeanDefinitionElement)。

首先获取到bean的class属性和parent属性，配置了parent之后，以后bean会继承父bean的属性。之后依据class和parent创立BeanDefinition对象。

String className = null;

if (ele.hasAttribute(CLASS_ATTRIBUTE)) {

className = ele.getAttribute(CLASS_ATTRIBUTE).trim();

}

String parent = null;

if (ele.hasAttribute(PARENT_ATTRIBUTE)) {

parent = ele.getAttribute(PARENT_ATTRIBUTE);

}

AbstractBeanDefinition bd = createBeanDefinition(className, parent);

BeanDefinition的创立在BeanDefinitionReaderUtils.createBeanDefinition:

public static AbstractBeanDefinition createBeanDefinition(

String parentName, String className, ClassLoader classLoader) {

GenericBeanDefinition bd = new GenericBeanDefinition();

bd.setParentName(parentName);

if (className != null) {

if (classLoader != null) {

bd.setBeanClass(ClassUtils.forName(className, classLoader));

}

else {

bd.setBeanClassName(className);

}

return bd;

}

BeanDefinition的创立在BeanDefinitionReaderUtils.createBeanDefinition:

public static AbstractBeanDefinition createBeanDefinition(

String parentName, String className, ClassLoader classLoader) {

GenericBeanDefinition bd = new GenericBeanDefinition();

bd.setParentName(parentName);

if (className != null) {

if (classLoader != null) {

bd.setBeanClass(ClassUtils.forName(className, classLoader));

}else {

bd.setBeanClassName(className);

}

return bd;

}

之后是解析bean的其它属性，其实就是读取其配置，调用相应的setter办法保留在BeanDefinition中:

parseBeanDefinitionAttributes(ele, beanName, containingBean, bd);

之后解析bean的decription子元素:

<description>SimpleBean</description>

</bean>

就仅仅是个形容。

而后是meta子元素的解析，meta元素在xml配置文件里是这样的:

</bean>

正文上说，这样能够将任意的元数据附到对应的bean definition上。解析过程源码:

public void parseMetaElements(Element ele, BeanMetadataAttributeAccessor attributeAccessor) {

NodeList nl = ele.getChildNodes();

for (int i = 0; i < nl.getLength(); i++) {

Node node = nl.item(i);

if (isCandidateElement(node) && nodeNameEquals(node, META_ELEMENT)) {

Element metaElement = (Element) node;

String key = metaElement.getAttribute(KEY_ATTRIBUTE);

String value = metaElement.getAttribute(VALUE_ATTRIBUTE);

//就是一个key, value的载体，无他

BeanMetadataAttribute attribute = new BeanMetadataAttribute(key, value);

//sourceExtractor默认是NullSourceExtractor，返回的是空

attribute.setSource(extractSource(metaElement));

attributeAccessor.addMetadataAttribute(attribute);

}

AbstractBeanDefinition继承自BeanMetadataAttributeAccessor类，底层应用了一个LinkedHashMap保留metadata。这个metadata具体是做什么临时还不晓得。

lookup-method解析：

此标签的作用在于当一个bean的某个办法被设置为lookup-method后，每次调用此办法时，都会返回一个新的指定bean的对象。用法示例:

<lookup-method name="getFruit" bean="apple"/>

</bean>

数据保留在Set中，对应的类是MethodOverrides。能够参考:

Spring - lookup-method形式实现依赖注入

replace-mothod解析:

此标签用于替换bean外面的特定的办法实现，替换者必须实现Spring的MethodReplacer接口，有点像aop的意思。

配置文件示例:

<replaced-method name="test" replacer="replacer">

<arg-type match="String" />

</replaced-method>

</bean>

arg-type的作用是指定替换办法的参数类型，因为接口的定义参数都是Object的。参考: SPRING.NET 1.3.2 学习20--办法注入之替换办法注入

解析之后将数据放在ReplaceOverride对象中，外面有一个LinkedList专门用于保留arg-type。

结构参数(constructor-arg)解析:

作用高深莫测，应用示例:

<constructor-arg>

</constructor-arg>

</bean>

type个别不须要指定，除了泛型汇合那种。除此之外，constructor-arg还反对name, index, ref等属性，能够具体的指定参数的地位等。结构参数解析后保留在BeanDefinition外部一个ConstructorArgumentValues对象中。如果设置了index属性，那么以Map<Integer, ValueHolder>的模式保留，反之，以List的模式保留。

property解析:

十分罕用的标签，用认为bean的属性赋值，反对value和ref两种模式，示例:

</bean>

value和ref属性不能同时呈现，如果是ref，那么将其值保留在不可变的RuntimeBeanReference对象中，其实现了BeanReference接口，此接口只有一个getBeanName办法。如果是value，那么将其值保留在TypedStringValue对象中。最终将对象保留在BeanDefinition外部一个MutablePropertyValues对象中(外部以ArrayList实现)。

qualifier解析:

配置示例:

</bean>

</bean>

SimpleBean局部源码:

@Autowired

@Qualifier("student")

private Student student;

此标签和@Qualifier, @Autowired两个注解一起应用才有作用。@Autowired注解采纳按类型查找的形式进行注入，如果找到多个须要类型的bean便会报错，有了@Qualifier标签就能够再依照此注解指定的名称查找。两者联合相当于实现了按类型+名称注入。type属性能够不指定，因为默认就是那个。qualifier标签能够有attribute子元素，比方:

</qualifier>

貌似是用来在qualifier也辨别不开的时候应用。attribute键值对保留在BeanMetadataAttribute对象中。整个qualifier保留在AutowireCandidateQualifier对象中。

Bean装璜

这部分是针对其它schema的属性以及子节点，比方:

<context:property-override />

</bean>

没见过这种用法，留个坑。

Bean注册

BeanDefinitionReaderUtils.registerBeanDefinition:

public static void registerBeanDefinition(

BeanDefinitionHolder definitionHolder, BeanDefinitionRegistry registry) {

// Register bean definition under primary name.

String beanName = definitionHolder.getBeanName();

registry.registerBeanDefinition(beanName, definitionHolder.getBeanDefinition());

// Register aliases for bean name, if any.

String[] aliases = definitionHolder.getAliases();

if (aliases != null) {

for (String alias : aliases) {

registry.registerAlias(beanName, alias);

}

registry其实就是DefaultListableBeanFactory对象，registerBeanDefinition办法次要就干了这么两件事:

@Overridepublic void registerBeanDefinition(String beanName, BeanDefinition beanDefinition) {

this.beanDefinitionMap.put(beanName, beanDefinition);

this.beanDefinitionNames.add(beanName);

}

一个是Map，另一个是List，高深莫测。registerAlias办法的实现在其父类SimpleAliasRegistry，就是把键值对放在了一个ConcurrentHashMap里。

ComponentRegistered事件触发:

默认是个空实现，后面说过了。

BeanDefinition数据结构(作者此处写成了BeanDefiniton 差之毫厘谬以千里怪不得找不到这个类)

BeanDefinition数据结构如下图:

beans

beans元素的嵌套间接递归调用DefaultBeanDefinitionDocumentReader.parseBeanDefinitions。

其它命名空间解析

入口在DefaultBeanDefinitionDocumentReader.parseBeanDefinitions->BeanDefinitionParserDelegate.parseCustomElement(第二个参数为空):

public BeanDefinition parseCustomElement(Element ele, BeanDefinition containingBd) {

String namespaceUri = getNamespaceURI(ele);

NamespaceHandler handler = this.readerContext.getNamespaceHandlerResolver().resolve(namespaceUri);

return handler.parse(ele, new ParserContext(this.readerContext, this, containingBd));

}

NamespaceHandlerResolver由XmlBeanDefinitionReader初始化，是一个DefaultNamespaceHandlerResolver对象，也是NamespaceHandlerResolver接口的惟一实现。

其resolve办法:

@Overridepublic NamespaceHandler resolve(String namespaceUri) {

Map<String, Object> handlerMappings = getHandlerMappings();

Object handlerOrClassName = handlerMappings.get(namespaceUri);

if (handlerOrClassName == null) {

return null;

} else if (handlerOrClassName instanceof NamespaceHandler) {

return (NamespaceHandler) handlerOrClassName;

} else {

String className = (String) handlerOrClassName;

Class<?> handlerClass = ClassUtils.forName(className, this.classLoader);//当前能够这样用

NamespaceHandler namespaceHandler = (NamespaceHandler) BeanUtils.instantiateClass(handlerClass);

namespaceHandler.init();

handlerMappings.put(namespaceUri, namespaceHandler);

return namespaceHandler;

}

容易看出，Spring其实应用了一个Map了保留其映射关系，key就是命名空间的uri，value是NamespaceHandler对象或是Class残缺名，如果发现是类名，那么用反射的办法进行初始化，如果是NamespaceHandler对象，那么间接返回。

NamespaceHandler映射关系来自于各个Spring jar包下的META-INF/spring.handlers文件，以spring-context包为例:

http\://www.springframework.org/schema/context=org.springframework.context.config.ContextNamespaceHandler

http\://www.springframework.org/schema/jee=org.springframework.ejb.config.JeeNamespaceHandler

http\://www.springframework.org/schema/lang=org.springframework.scripting.config.LangNamespaceHandler

http\://www.springframework.org/schema/task=org.springframework.scheduling.config.TaskNamespaceHandler

http\://www.springframework.org/schema/cache=org.springframework.cache.config.CacheNamespaceHandler

NamespaceHandler继承体系

init

resolve中调用了其init办法，此办法用以向NamespaceHandler对象注册BeanDefinitionParser对象。此接口用以解析顶层(beans下)的非默认命名空间元素，比方<context:annotation-config />。

所以这样逻辑就很容易了解了: 每种子标签的解析仍是策略模式的体现，init负责向父类NamespaceHandlerSupport注册不同的策略，由父类的NamespaceHandlerSupport.parse办法依据具体的子标签调用相应的策略实现解析的过程。

此局部较为重要，所以从新开始纲要。

BeanFactory数据结构

BeanDefinition在BeanFactory中的次要数据结构如下图:

prepareBeanFactory

此办法负责对BeanFactory进行一些特色的设置工作，"特色"蕴含这么几个方面:

BeanExpressionResolver

此接口只有一个实现: StandardBeanExpressionResolver。接口只含有一个办法:

Object evaluate(String value, BeanExpressionContext evalContext)

prepareBeanFactory将一个此对象放入BeanFactory:

beanFactory.setBeanExpressionResolver(new StandardBeanExpressionResolver(beanFactory.getBeanClassLoader()));

StandardBeanExpressionResolver对象外部有一个要害的成员: SpelExpressionParser,其整个类图:

这便是Spring3.0开始呈现的Spel表达式的解释器。

PropertyEditorRegistrar

此接口用于向Spring注册java.beans.PropertyEditor，只有一个办法:

registerCustomEditors(PropertyEditorRegistry registry)

实现也只有一个: ResourceEditorRegistrar。

在编写xml配置时，咱们设置的值都是字符串模式，所以在应用时必定须要转为咱们须要的类型，PropertyEditor接口正是定义了这么个货色。

prepareBeanFactory:

beanFactory.addPropertyEditorRegistrar(new ResourceEditorRegistrar(this, getEnvironment()));

BeanFactory也裸露了registerCustomEditors办法用以增加自定义的转换器，所以这个中央是组合模式的体现。

咱们有两种形式能够增加自定义PropertyEditor:

通过context.getBeanFactory().registerCustomEditor
通过Spring配置文件:
<bean class="org.springframework.beans.factory.config.CustomEditorConfigurer">
<property name="customEditors">
<map>
<entry key="base.Cat" value="base.CatEditor" />
</map>
</property>
</bean>

参考: 深刻了解JavaBean(2)：属性编辑器PropertyEditor

环境注入

其实上面的一切都是围绕这个AbstractApplicationContext.prepareBeanFactory办法办法开展的。**

在Spring中咱们本人的bean能够通过实现EnvironmentAware等一系列Aware接口获取到Spring外部的一些对象。prepareBeanFactory:

beanFactory.addBeanPostProcessor(new ApplicationContextAwareProcessor(this));//

private void invokeAwareInterfaces(Object bean) {

if (bean instanceof Aware) {

if (bean instanceof EnvironmentAware) {

((EnvironmentAware)bean).setEnvironment(this.applicationContext.getEnvironment());

}

if (bean instanceof EmbeddedValueResolverAware) {

((EmbeddedValueResolverAware)bean).setEmbeddedValueResolver(new ApplicationContextAwareProcessor.EmbeddedValueResolver(this.applicationContext.getBeanFactory()));

}

//....

}

此局部设置哪些接口在进行依赖注入的时候应该被疏忽:

beanFactory.ignoreDependencyInterface(ResourceLoaderAware.class);

beanFactory.ignoreDependencyInterface(ApplicationEventPublisherAware.class);

beanFactory.ignoreDependencyInterface(MessageSourceAware.class);

beanFactory.ignoreDependencyInterface(ApplicationContextAware.class);

beanFactory.ignoreDependencyInterface(EnvironmentAware.class);

bean假装

有些对象并不在BeanFactory中，然而咱们仍然想让它们能够被拆卸，这就须要假装一下:

beanFactory.registerResolvableDependency(BeanFactory.class, beanFactory);

beanFactory.registerResolvableDependency(ResourceLoader.class, this);

beanFactory.registerResolvableDependency(ApplicationEventPublisher.class, this);

beanFactory.registerResolvableDependency(ApplicationContext.class, this);

假装关系保留在一个Map<Class<?>, Object>里。

LoadTimeWeaver

如果配置了此bean，那么：

if (beanFactory.containsBean(LOAD_TIME_WEAVER_BEAN_NAME)) { //增加后置处理器理论就是“loadTimeWeaver”

beanFactory.addBeanPostProcessor(new LoadTimeWeaverAwareProcessor(beanFactory));

// Set a temporary ClassLoader for type matching.

beanFactory.setTempClassLoader(new ContextTypeMatchClassLoader(beanFactory.getBeanClassLoader()));

}

这个货色具体是干什么的在前面context:load-time-weaver中阐明。

注册环境

源码:

if (!beanFactory.containsLocalBean(ENVIRONMENT_BEAN_NAME)) {//environment 可见下图

beanFactory.registerSingleton(ENVIRONMENT_BEAN_NAME, getEnvironment());

}

if (!beanFactory.containsLocalBean(SYSTEM_PROPERTIES_BEAN_NAME)) {

beanFactory.registerSingleton(SYSTEM_PROPERTIES_BEAN_NAME, getEnvironment().getSystemProperties());

}

if (!beanFactory.containsLocalBean(SYSTEM_ENVIRONMENT_BEAN_NAME)) {

beanFactory.registerSingleton(SYSTEM_ENVIRONMENT_BEAN_NAME, getEnvironment().

getSystemEnvironment());

}

containsLocalBean非凡之处在于不会去父BeanFactory寻找。

postProcessBeanFactory

此办法容许子类在所有的bean尚未初始化之前注册BeanPostProcessor。空实现且没有子类笼罩。

invokeBeanFactoryPostProcessors

BeanFactoryPostProcessor接口容许咱们在bean正是初始化之前扭转其值。此接口只有一个办法:

void postProcessBeanFactory(ConfigurableListableBeanFactory beanFactory);

有两种形式能够向Spring增加此对象:

通过代码的形式:
context.addBeanFactoryPostProcessor
通过xml配置的形式:
<bean class="base.SimpleBeanFactoryPostProcessor" />

留神此时尚未进行bean的初始化工作，初始化是在前面的finishBeanFactoryInitialization进行的，所以在BeanFactoryPostProcessor对象中获取bean会导致提前初始化。

此办法的要害源码:

protected void invokeBeanFactoryPostProcessors(ConfigurableListableBeanFactory beanFactory) {

PostProcessorRegistrationDelegate.invokeBeanFactoryPostProcessors(beanFactory,

getBeanFactoryPostProcessors());

}

getBeanFactoryPostProcessors获取的就是AbstractApplicationContext的成员beanFactoryPostProcessors(ArrayList)，然而很有意思，只有通过context.addBeanFactoryPostProcessor这种形式增加的才会呈现在这个List里，所以对于xml配置形式，此List其实没有任何元素。玄机就在PostProcessorRegistrationDelegate里。

核心思想就是应用BeanFactory的getBeanNamesForType办法获取相应的BeanDefinition的name数组，之后逐个调用getBean办法获取到bean(初始化)，getBean办法前面再说。

留神此处有一个优先级的概念，如果你的BeanFactoryPostProcessor同时实现了Ordered或者是PriorityOrdered接口，那么会被首先执行。

BeanPostProcessor注册

此局部本质上是在BeanDefinitions中寻找BeanPostProcessor，之后调用BeanFactory.addBeanPostProcessor办法保留在一个List中，留神增加时依然有优先级的概念，优先级高的在后面。

（AbstractApplicationContext.refresh外面的办法 initMessageSource；初始化MessageSource）

MessageSource

此接口用以反对Spring国际化。继承体系如下:

AbstractApplicationContext的initMessageSource()办法就是在BeanFactory中查找MessageSource的bean，如果配置了此bean，那么调用getBean办法实现其初始化并将其保留在AbstractApplicationContext外部messageSource成员变量中，用以解决ApplicationContext的getMessage调用，因为从继承体系上来看，ApplicationContext是MessageSource的子类，此处是委托模式的体现。如果没有配置此bean，那么初始化一个DelegatingMessageSource对象，此类是一个空实现，同样用以解决getMessage调用申请。

参考: 学习Spring必学的Java基础知识(8)----国际化信息

事件驱动

4.1.1版本源码

protected void initApplicationEventMulticaster() {

ConfigurableListableBeanFactory beanFactory = this.getBeanFactory();

if (beanFactory.containsLocalBean("applicationEventMulticaster")) {

this.applicationEventMulticaster = (ApplicationEventMulticaster)beanFactory.getBean("applicationEventMulticaster", ApplicationEventMulticaster.class);

if (this.logger.isDebugEnabled()) {

this.logger.debug("Using ApplicationEventMulticaster [" + this.applicationEventMulticaster + "]");

}

} else {

this.applicationEventMulticaster = new SimpleApplicationEventMulticaster(beanFactory);

beanFactory.registerSingleton("applicationEventMulticaster", this.applicationEventMulticaster);

if (this.logger.isDebugEnabled()) {

this.logger.debug("Unable to locate ApplicationEventMulticaster with name 'applicationEventMulticaster': using default [" + this.applicationEventMulticaster + "]");

}

此接口代表了Spring的事件驱动(监听器)模式。一个事件驱动蕴含三局部:

事件

java的所有事件对象个别都是java.util.EventObject的子类，Spring的整个继承体系如下:

发布者

ApplicationEventPublisher（可见上图）

高深莫测。

ApplicationEventMulticaster

ApplicationEventPublisher实际上正是将申请委托给ApplicationEventMulticaster来实现的。其继承体系:

监听器

所有的监听器是jdk EventListener的子类，这是一个mark接口。继承体系:

事件公布

AbstractApplicationContext.publishEvent外围代码:

protected void publishEvent(Object event, ResolvableType eventType) {

getApplicationEventMulticaster().multicastEvent(applicationEvent, eventType);

}

SimpleApplicationEventMulticaster.multicastEvent:

@Overridepublic void multicastEvent(final ApplicationEvent event, ResolvableType eventType) {

ResolvableType type = (eventType != null ? eventType : resolveDefaultEventType(event));

for (final ApplicationListener<?> listener : getApplicationListeners(event, type)) {

Executor executor = getTaskExecutor();

if (executor != null) {

executor.execute(new Runnable() {

@Override

public void run() {

invokeListener(listener, event);

}

});

} else {

invokeListener(listener, event);

}

监听器获取

获取当然还是通过beanFactory的getBean来实现的，值得注意的是Spring在此处应用了缓存(ConcurrentHashMap)来减速查找的过程。

同步/异步

能够看出，如果executor不为空，那么监听器的执行实际上是异步的。那么如何配置同步/异步呢?

全局

<task:executor id="multicasterExecutor" pool-size="3"/>

</bean>

task schema是Spring从3.0开始退出的，使咱们能够不再依赖于Quartz实现定时工作，源码在org.springframework.core.task包下，应用须要引入schema：

xmlns:task="http://www.springframework.org/schema/task"

xsi:schemaLocation="http://www.springframework.org/schema/taskhttp://www.springframework.or...d"

能够参考: Spring定时工作的几种实现

注解

开启注解反对:

<aop:aspectj-autoproxy proxy-target-class="true"/>

<task:scheduler id="scheduler" pool-size="10"/>

<task:executor id="executor" pool-size="10"/>

<task:annotation-driven executor="executor" scheduler="scheduler" proxy-target-class="true"/>

在代码中应用示例:

@Component

public class EmailRegisterListener implements ApplicationListener<RegisterEvent> {

@Async

@Override

public void onApplicationEvent(final RegisterEvent event) {

System.out.println("注册胜利，发送确认邮件给：" + ((User)event.getSource()).getUsername());

}

参考: 详解Spring事件驱动模型

onRefresh

这又是一个模版办法，容许子类在进行bean初始化之前进行一些定制操作。默认空实现。

ApplicationListener注册

registerListeners办法干的，没什么好说的

singleton初始化

finishBeanFactoryInitialization：

protected void finishBeanFactoryInitialization(ConfigurableListableBeanFactory beanFactory) {

if (beanFactory.containsBean(CONVERSION_SERVICE_BEAN_NAME) &&

beanFactory.isTypeMatch(CONVERSION_SERVICE_BEAN_NAME, ConversionService.class)) {

beanFactory.setConversionService(

beanFactory.getBean(CONVERSION_SERVICE_BEAN_NAME, ConversionService.class));

}

if (!beanFactory.hasEmbeddedValueResolver()) {

beanFactory.addEmbeddedValueResolver(new StringValueResolver() {

@Override

public String resolveStringValue(String strVal) {

return getEnvironment().resolvePlaceholders(strVal);

}

});

}

String[] weaverAwareNames = beanFactory.getBeanNamesForType

(LoadTimeWeaverAware.class, false, false);

for (String weaverAwareName : weaverAwareNames) {

getBean(weaverAwareName);

}

// Allow for caching all bean definition metadata, not expecting further changes.

beanFactory.freezeConfiguration();

// Instantiate all remaining (non-lazy-init) singletons.

beanFactory.preInstantiateSingletons();

}

分局部阐明。

ConversionService

此接口用于类型之间的转换，在Spring里其实就是把配置文件中的String转为其它类型，从3.0开始呈现，目标和jdk的PropertyEditor接口是一样的，参考ConfigurableBeanFactory.setConversionService正文:

Specify a Spring 3.0 ConversionService to use for converting property values, as an alternative to JavaBeans PropertyEditors. @since 3.0

StringValueResolver

用于解析注解的值。接口只定义了一个办法:

String resolveStringValue(String strVal);

LoadTimeWeaverAware

实现了此接口的bean能够失去LoadTimeWeaver，此处仅仅初始化。

初始化

DefaultListableBeanFactory.preInstantiateSingletons:

@Overridepublic void preInstantiateSingletons() throws BeansException {

List<String> beanNames = new ArrayList<String>(this.beanDefinitionNames);

for (String beanName : beanNames) {

RootBeanDefinition bd = getMergedLocalBeanDefinition(beanName);

if (!bd.isAbstract() && bd.isSingleton() && !bd.isLazyInit()) {

if (isFactoryBean(beanName)) {

final FactoryBean<?> factory = (FactoryBean<?>) getBean(FACTORY_BEAN_PREFIX

+ beanName);

boolean isEagerInit;

if (System.getSecurityManager() != null && factory instanceof SmartFactoryBean) {

isEagerInit = AccessController.doPrivileged(new PrivilegedAction<Boolean>() {

@Override

public Boolean run() {

return ((SmartFactoryBean<?>) factory).isEagerInit();

}

}, getAccessControlContext());

}

else {

isEagerInit = (factory instanceof SmartFactoryBean &&

((SmartFactoryBean<?>) factory).isEagerInit());

}

if (isEagerInit) {

getBean(beanName);

}

else {

getBean(beanName);

}

// Trigger post-initialization callback for all applicable beans...

for (String beanName : beanNames) {

Object singletonInstance = getSingleton(beanName);

if (singletonInstance instanceof SmartInitializingSingleton) {

final SmartInitializingSingleton smartSingleton =

(SmartInitializingSingleton) singletonInstance;

if (System.getSecurityManager() != null) {

AccessController.doPrivileged(new PrivilegedAction<Object>() {

@Override

public Object run() {

smartSingleton.afterSingletonsInstantiated();

return null;

}

}, getAccessControlContext());

}

else {

smartSingleton.afterSingletonsInstantiated();

}

首先进行Singleton的初始化，其中如果bean是FactoryBean类型(留神，只定义了factory-method属性的一般bean并不是FactoryBean)，并且还是SmartFactoryBean类型，那么须要判断是否须要eagerInit(isEagerInit是此接口定义的办法)。

本文来源于：宋文超super，专属平台有csdn、思否(SegmentFault)、简书、开源中国(oschina)，转载请注明出处。