一、概述

1.1> 整体概览

在前面的内容中，我们针对BeanFactory进行了深度的分析。那么，下面我们将针对BeanFactory的功能扩展类ApplicationContext进行深度的分析。ApplicationConext与BeanFactory的功能相似，都是用于向IOC中加载Bean的。由于ApplicationConext的功能是大于BeanFactory的，所以在日常使用中，建议直接使用ApplicationConext即可。下面是两个类使用示例：

ApplicationConext是接口，所以要分析其加载bean的流程，就可以从ClassPathXmlApplicationContext入手，其构造函数如下所示：

public ClassPathXmlApplicationContext(String configLocation) throws BeansException {
	this(new String[] {configLocation}, true, null);
}

public ClassPathXmlApplicationContext(String[] configLocations, boolean refresh, ApplicationContext parent) {
	super(parent);
	setConfigLocations(configLocations); // 事情1：设置配置加载路径
	if (refresh) refresh(); // 事情2：所有功能的初始化操作
}

在上面的构造方法中，主要做了两个事情： 【事情1】设置配置的加载路径； 【事情2】执行ApplicationConext中，所有功能的初始化操作； 下面文章的内容，我们就是会针对这两部分做详细的解析：

1.2> setConfigLocations(...) 设置配置加载路径

该方法逻辑不多，主要就是为应用上下文ApplicationContext设置配置路径（config locations），源码如下所示：

public void setConfigLocations(String... locations) { // 支持传入多个配置文件
	if (locations != null) {
		this.configLocations = new String[locations.length];
		for (int i = 0; i < locations.length; i++) 
			this.configLocations[i] = resolvePath(locations[i]).trim(); // 路径解析
	} else 
        this.configLocations = null;
}

// 如果路径中包含特殊符号（如：${var}）,那么在resolvePath方法中会搜寻匹配的系统变量并且进行替换操作
protected String resolvePath(String path) {
    // 调用AbstractPropertyResolver#resolveRequiredPlaceholders(path)方法
    return getEnvironment().resolveRequiredPlaceholders(path); 
}

1.3> refresh() 初始化

在refresh()方法中几乎包含了ApplicationContext中提供的全部功能，下面我们会针对这个方法进行详细的分析：

public void refresh() throws BeansException, IllegalStateException {
	synchronized (this.startupShutdownMonitor) {
		prepareRefresh(); /** 步骤1：为refresh操作做提前的准备工作 */
		ConfigurableListableBeanFactory beanFactory = obtainFreshBeanFactory(); /** 步骤2：获得beanFactory实例对象 */
		prepareBeanFactory(beanFactory); /** 步骤3：准备用于此上下文的beanFactory */
		try {
			postProcessBeanFactory(beanFactory); // 允许在上下文子类中对BeanFactory进行后置处理（空方法，可由子类实现）
			invokeBeanFactoryPostProcessors(beanFactory); /** 步骤4：激活各种BeanFactory的后置处理器 */
			registerBeanPostProcessors(beanFactory); /** 步骤5：注册各种Bean的后置处理器，在getBean时才会被调用 */
			initMessageSource(); /** 步骤6：为上下文初始化消息源（即：国际化处理）*/
			initApplicationEventMulticaster(); /** 步骤7：为上下文初始化应用事件广播器 */
			onRefresh(); // 初始化特定上下文子类中的其他特殊bean（空方法，可由子类实现）
			registerListeners(); /** 步骤8：在所有注册的bean中查找listener bean，并注册到消息广播器中 */
			finishBeanFactoryInitialization(beanFactory); /** 步骤9：初始化剩下的单例（非惰性non-lazy-init）*/
			finishRefresh(); /** 步骤10：完成refresh，通知lifecycleProcessor刷新过程，同时发出ContextRefreshEvent通知 */
		}
		catch (BeansException ex) {
			destroyBeans(); // Destroy already created singletons to avoid dangling resources
			cancelRefresh(ex); // Reset 'active' flag
			throw ex;
		}
		finally {resetCommonCaches();}
	}
}

二、prepareRefresh()准备工作

下面我们来分析一下refresh()方法中的prepareRefresh()代码段的处理逻辑：

针对prepareRefresh()方法来说，主要就包含如下注释的两个方法，看似没什么意义，但是如果我们自定义了ClassPathXmlApplicationContext类，那么可以通过重写initPropertySources()方法，来增加逻辑代码：

protected void prepareRefresh() {
	...
	this.active.set(true); 
	initPropertySources(); // 空方法，可以由子类重写
	getEnvironment().validateRequiredProperties(); /** 验证需要的属性文件是否都已经放入环境中 */
	...
}

public void validateRequiredProperties() throws MissingRequiredPropertiesException {
	this.propertyResolver.validateRequiredProperties();
}

public void validateRequiredProperties() {
	MissingRequiredPropertiesException ex = new MissingRequiredPropertiesException();
	for (String key : this.requiredProperties) 
        // 如果环境中没有配置所需属性，则将缺失的属性放到ex中，并抛出异常
		if (this.getProperty(key) == null) 
            ex.addMissingRequiredProperty(key); 
	if (!ex.getMissingRequiredProperties().isEmpty()) {throw ex;}
}

三、obtainFreshBeanFactory()获得最新BeanFactory

下面我们来分析一下refresh()方法中的obtainFreshBeanFactory()代码段的处理逻辑：

通过obtainFreshBeanFactory()这个方法，ApplicationContext就已经拥有了BeanFactory的全部功能。而这个方法中也包含了前面我们介绍BeanFactory时候对于xml配置的加载过程。

protected ConfigurableListableBeanFactory obtainFreshBeanFactory() {
	refreshBeanFactory(); /** 初始化BeanFactory */
	return getBeanFactory(); 
}

在refreshBeanFactory()方法中，在基本容器的基础上，增加了是否允许覆盖 和 是否允许扩展的设置，并提供了注解 @Qualifier 和 @Autowired 的支持。

protected final void refreshBeanFactory() throws BeansException {
	if (hasBeanFactory()) {destroyBeans();closeBeanFactory();}

	try {
		DefaultListableBeanFactory beanFactory = createBeanFactory(); // new一个beanFactory的实例对象
		beanFactory.setSerializationId(getId());
		customizeBeanFactory(beanFactory); // 定制化操作BeanFactory配置
		loadBeanDefinitions(beanFactory); /** 初始化XmlBeanDefinitionReader，并进行xml配置文件读取及解析 */
		this.beanFactory = beanFactory;
	}
	catch (IOException ex) {throw new ApplicationContextException(...);}
}

/** 该方法可以采用子类覆盖的方式改变里面的逻辑内容 */
protected void customizeBeanFactory(DefaultListableBeanFactory beanFactory) {
	if (this.allowBeanDefinitionOverriding != null) // 设置是否允许覆盖同名称且不同定义的beanDefinition实例
		beanFactory.setAllowBeanDefinitionOverriding(this.allowBeanDefinitionOverriding);
	if (this.allowCircularReferences != null) // 设置是否允许bean直接存在循环依赖
		beanFactory.setAllowCircularReferences(this.allowCircularReferences);
}

在loadBeanDefinitions(beanFactory)方法中，执行了初始化XmlBeanDefinitionReader操作，并且进行xml配置文件读取及解析

protected void loadBeanDefinitions(DefaultListableBeanFactory beanFactory) throws BeansException, IOException {
    // 创建XmlBeanDefinitionReader，用于后续对配置的读取操作
	XmlBeanDefinitionReader beanDefinitionReader = new XmlBeanDefinitionReader(beanFactory);
	beanDefinitionReader.setEnvironment(this.getEnvironment());
	beanDefinitionReader.setResourceLoader(this);
	beanDefinitionReader.setEntityResolver(new ResourceEntityResolver(this));

	initBeanDefinitionReader(beanDefinitionReader); // 对beanDefinitionReader进行设置，可以被子类覆盖
	loadBeanDefinitions(beanDefinitionReader); /** 加载xml配置信息 */
}

/** 对XmlBeanDefinitionReader进行设置（此方法可以由子类进行覆写） */
protected void initBeanDefinitionReader(XmlBeanDefinitionReader reader) {
	reader.setValidating(this.validating); // validating = true
}

当获得了XmlBeanDefinitionReader之后，我们就可以通过loadBeanDefinitions(beanDefinitionReader)方法对xml配置文件进行读取操作了。其中的reader.loadBeanDefinitions(...)方法我们在前面的BeanFactory配置文件读取操作中已经解析过了，此处就不再赘述。

protected void loadBeanDefinitions(XmlBeanDefinitionReader reader) throws BeansException, IOException {
	// 尝试获得xml配置文件的Resource实例集合，并进行配置加载
    Resource[] configResources = getConfigResources();  
	if (configResources != null) reader.loadBeanDefinitions(configResources);

    // 尝试获得xml配置文件路径集合，并进行配置加载
	String[] configLocations = getConfigLocations(); 
	if (configLocations != null) reader.loadBeanDefinitions(configLocations);
}

四、prepareBeanFactory(...)准备用于此上下文的beanFactory

4.1> 整体概览

下面我们来分析一下refresh()方法中的prepareBeanFactory()代码段的处理逻辑：

当执行本方法之前，Spring已经完成了对配置的解析操作，而从本方法开始，ApplicationContext在功能上的扩展也由此展开了。

protected void prepareBeanFactory(ConfigurableListableBeanFactory beanFactory) {
	// 将当前上下文的classLoader作为beanFactory的classLoader
    beanFactory.setBeanClassLoader(getClassLoader()); 

	// 是否支持SpEL表达式解析，即：可以使用#{bean.xxx}的形式来调用相关属性值
	if (!shouldIgnoreSpel) 
		beanFactory.setBeanExpressionResolver(new StandardBeanExpressionResolver(beanFactory.getBeanClassLoader()));

	// 添加1个属性编辑器，它是对bean的属性等设置管理的工具
	beanFactory.addPropertyEditorRegistrar(new ResourceEditorRegistrar(this, getEnvironment()));

	// 添加1个bean的后置处理器
	beanFactory.addBeanPostProcessor(new ApplicationContextAwareProcessor(this)); 

	// 设置7个需要忽略自动装配的接口
	beanFactory.ignoreDependencyInterface(EnvironmentAware.class);
	beanFactory.ignoreDependencyInterface(EmbeddedValueResolverAware.class);
	beanFactory.ignoreDependencyInterface(ResourceLoaderAware.class);
	beanFactory.ignoreDependencyInterface(ApplicationEventPublisherAware.class);
	beanFactory.ignoreDependencyInterface(MessageSourceAware.class);
	beanFactory.ignoreDependencyInterface(ApplicationContextAware.class);
	beanFactory.ignoreDependencyInterface(ApplicationStartupAware.class);

	// 注册4个依赖
	beanFactory.registerResolvableDependency(BeanFactory.class, beanFactory);
	beanFactory.registerResolvableDependency(ResourceLoader.class, this);
	beanFactory.registerResolvableDependency(ApplicationEventPublisher.class, this);
	beanFactory.registerResolvableDependency(ApplicationContext.class, this);

	// 添加1个bean的后置处理器
	beanFactory.addBeanPostProcessor(new ApplicationListenerDetector(this));

	// 增加对AspectJ的支持
	if (!NativeDetector.inNativeImage() && beanFactory.containsBean(LOAD_TIME_WEAVER_BEAN_NAME)) {
		beanFactory.addBeanPostProcessor(new LoadTimeWeaverAwareProcessor(beanFactory));
		beanFactory.setTempClassLoader(new ContextTypeMatchClassLoader(beanFactory.getBeanClassLoader()));
	}

	// 注册4个默认的系统环境bean
	if (!beanFactory.containsLocalBean(ENVIRONMENT_BEAN_NAME)) // environment
		beanFactory.registerSingleton(ENVIRONMENT_BEAN_NAME, getEnvironment());
	if (!beanFactory.containsLocalBean(SYSTEM_PROPERTIES_BEAN_NAME)) // systemProperties
		beanFactory.registerSingleton(SYSTEM_PROPERTIES_BEAN_NAME, getEnvironment().getSystemProperties());
	if (!beanFactory.containsLocalBean(SYSTEM_ENVIRONMENT_BEAN_NAME)) // systemEnvironment
		beanFactory.registerSingleton(SYSTEM_ENVIRONMENT_BEAN_NAME, getEnvironment().getSystemEnvironment());
	if (!beanFactory.containsLocalBean(APPLICATION_STARTUP_BEAN_NAME)) // applicationStartup
		beanFactory.registerSingleton(APPLICATION_STARTUP_BEAN_NAME, getApplicationStartup());
}

4.2> 添加对SpEL表达式的支持

SpEL全称是“Spring Expression Language”，它能在运行时构件复杂表达式、存取对象图属性、对象方法调用等；它是单独模块，只依赖了core模块，所以可以单独使用。SpEL使用 #{...} 作为界定符，所有在大括号中的字符都会被认定为SpEL，使用方式如下所示：

<bean id="user" value="com.muse.entity.User"/>
<bean ...>
    <property name="name" value="#{user}">
</bean>
    
相当于：
    
<bean id="user" value="com.muse.entity.User"/>
<bean ...>
    <property name="name" ref="user">
</bean>

在 prepareBeanFactory(beanFactory) 方法中，通过beanFactory.setBeanExpressionResolver(new StandardBeanExpressionResolver(...))注册SpEL语言解析器，就可以对SpEL进行解析了。

那么，在注册了解析器后，**Spring又是在什么时候调用这个解析器进行解析操作的呢？**调用方式如下图所示：

【解释】其实就是在Spring进行bean初始化的时候，有一个步骤是——属性填充（即：populateBean()），而在这一步中Spring会调用AbstractAutowireCapableBeanFactory#applyPropertyValues(...)方法来完成功能。而就在这个方法中，会创建BeanDefinitionValueResolver实例对象valueResolver来进行属性值的解析操作。同时，也是在这个步骤中，通过AbstractBeanFactory#evaluateBeanDefinitionString(...)方法去完成SpEL的解析操作。

相关源码如下所示：

protected Object evaluateBeanDefinitionString(String value, BeanDefinition beanDefinition) {
	if (this.beanExpressionResolver == null) return value;
	Scope scope = null;
	if (beanDefinition != null) {
		String scopeName = beanDefinition.getScope();
		if (scopeName != null) scope = getRegisteredScope(scopeName);
	}
    // 通过获得的beanExpressionResolver实例调用evaluate(...)方法执行解析操作
	return this.beanExpressionResolver.evaluate(value, new BeanExpressionContext(this, scope));
}

4.3> 添加属性编辑器

下面我们继续来介绍一下beanFactory.addPropertyEditorRegistrar(new ResourceEditorRegistrar(this, getEnvironment()));这行代码，那么通过调用的方法名称，我们可以猜到它的作用是给BeanFactory实例添加属性编辑器。那么，什么是属性编辑器呢？ 在Spring加载bean的时候，可以把基本类型属性注入进来，但是对于类似Date这种复杂属性就无法被识别了。

4.3.1> 属性编辑器的应用

我们假设有一个Schedule类，其中包含了一个Date类型的属性，如果采用默认加载方式的话，是无法将xml中配置的"2023-01-01"值转换为Date类型的。那么，下面我们就来演示一下如何通过自定义属性编辑器来让Spring在加载bean的时候，将String类型的值转换为Date类型的值。如下所示：

@Data
public class Schedule {
    private String name;
    private Date date; // 添加Date类型的属性
}

<bean id="schedule" class="com.muse.springbootdemo.entity.propertyeditor.Schedule">
  <property name="name" value="work"/>
  <property name="date" value="2023-01-01"/> <!-- date是Date类型，需要将String转换为Date -->
</bean>

当我们运行的时候发现报错了，即：无法将配置文件中的String类型转换为Date类型：

那么，我们添加用来将String类型转换为Date类型的属性编译器DatePropertyEditor，并将其注入到CustomEditorConfigurer中即可。

public class DatePropertyEditor implements PropertyEditorRegistrar {
    @Override
    public void registerCustomEditors(PropertyEditorRegistry registry) {
        registry.registerCustomEditor(Date.class, new CustomDateEditor(new SimpleDateFormat("yyyy-MM-dd"), true));
    }
}

<!-- 注册属性编辑器 -->
<bean class="org.springframework.beans.factory.config.CustomEditorConfigurer">
    <property name="propertyEditorRegistrars"> <!-- 将自定义属性编辑器保存到propertyEditorRegistrars属性中 -->
        <list>
            <bean class="com.muse.springbootdemo.entity.propertyeditor.DatePropertyEditor"/>
        </list>
    </property>
</bean>

在调用registerCustomEditor(...)方法的时候，我们创建了CustomDateEditor实例对象，在此处我们只是来看一下它的类继承关系，下文还会涉及对它的介绍。

4.3.2> 源码解析

通过上面对于注册属性编辑器的配置，我们可以看到自定义的属性编辑器DatePropertyEditor被保存到了CustomEditorConfigurer的propertyEditorRegistrars属性中，那么由于CustomEditorConfigurer类实现了BeanFactoryPostProcessor接口，所以当bean初始化的时候，会调用它的postProcessBeanFactory(...)方法，那么在这个方法中，会将propertyEditorRegistrars属性中的所有属性编辑器添加到beanFactory中。

那么，我们在回头来看 beanFactory.addPropertyEditorRegistrar(new ResourceEditorRegistrar(this, getEnvironment())) 的这行代码，其实也是同样的调用方式：

那么，我们分析到这一步之后，发现自定义属性编辑器都会保存到ConfigurableListableBeanFactory实例对象beanFactory的变量propertyEditorRegistrars中。那么问题来了——保存我们知道了，那什么时候属性编辑器会被调用呢？ 其实就是在初始化bean的时候，在initBeanWrapper(...)方法中，会被调用。

那么综上所述，我们来通过一张图，了解一下属性编辑器的注册和使用操作相关的类关系图：

在上面的例子中，我们自定义了一个属性编辑器DatePropertyEditor，其实Spring也内置了自己的属性编辑器ResourceEditorRegistrar。

在ResourceEditorRegistrar的registerCustomEditors(...)方法中，提供了Spring默认配置的所有属性编辑器集合。如下所示：

在doRegisterEditor(...)中，我们发现该方法的内部实现与自定义属性编辑器实现方式基本一样，即：通过调用registry.registerCustomEditor(requiredType, editor)方法来注册属性编辑器。如下所示：

此处我们再提及一点，就是在PropertyEditorRegistrySupport类的createDefaultEditors()方法中，包含了Spring给我们提供的一系列默认编辑器。具体如下所示：

private void createDefaultEditors() {
	this.defaultEditors = new HashMap<>(64);
    
    // Simple editors, without parameterization capabilities.
	this.defaultEditors.put(Charset.class, new CharsetEditor());
	this.defaultEditors.put(Class.class, new ClassEditor());
	this.defaultEditors.put(Class[].class, new ClassArrayEditor());
	this.defaultEditors.put(Currency.class, new CurrencyEditor());
	this.defaultEditors.put(File.class, new FileEditor());
	this.defaultEditors.put(InputStream.class, new InputStreamEditor());
	if (!shouldIgnoreXml) 
		this.defaultEditors.put(InputSource.class, new InputSourceEditor());
	this.defaultEditors.put(Locale.class, new LocaleEditor());
	this.defaultEditors.put(Path.class, new PathEditor());
	this.defaultEditors.put(Pattern.class, new PatternEditor());
	this.defaultEditors.put(Properties.class, new PropertiesEditor());
	this.defaultEditors.put(Reader.class, new ReaderEditor());
	this.defaultEditors.put(Resource[].class, new ResourceArrayPropertyEditor());
	this.defaultEditors.put(TimeZone.class, new TimeZoneEditor());
	this.defaultEditors.put(URI.class, new URIEditor());
	this.defaultEditors.put(URL.class, new URLEditor());
	this.defaultEditors.put(UUID.class, new UUIDEditor());
	this.defaultEditors.put(ZoneId.class, new ZoneIdEditor());
    
	// Default instances of collection editors.
	this.defaultEditors.put(Collection.class, new CustomCollectionEditor(Collection.class));
	this.defaultEditors.put(Set.class, new CustomCollectionEditor(Set.class));
	this.defaultEditors.put(SortedSet.class, new CustomCollectionEditor(SortedSet.class));
	this.defaultEditors.put(List.class, new CustomCollectionEditor(List.class));
	this.defaultEditors.put(SortedMap.class, new CustomMapEditor(SortedMap.class));
    
	// Default editors for primitive arrays.
	this.defaultEditors.put(byte[].class, new ByteArrayPropertyEditor());
	this.defaultEditors.put(char[].class, new CharArrayPropertyEditor());
    
	// The JDK does not contain a default editor for char!
	this.defaultEditors.put(char.class, new CharacterEditor(false));
	this.defaultEditors.put(Character.class, new CharacterEditor(true));
    
	// Spring's CustomBooleanEditor accepts more flag values than the JDK's default editor.
	this.defaultEditors.put(boolean.class, new CustomBooleanEditor(false));
	this.defaultEditors.put(Boolean.class, new CustomBooleanEditor(true));
    
	// The JDK does not contain default editors for number wrapper types!
	// Override JDK primitive number editors with our own CustomNumberEditor.
	this.defaultEditors.put(byte.class, new CustomNumberEditor(Byte.class, false));
	this.defaultEditors.put(Byte.class, new CustomNumberEditor(Byte.class, true));
	this.defaultEditors.put(short.class, new CustomNumberEditor(Short.class, false));
	this.defaultEditors.put(Short.class, new CustomNumberEditor(Short.class, true));
	this.defaultEditors.put(int.class, new CustomNumberEditor(Integer.class, false));
	this.defaultEditors.put(Integer.class, new CustomNumberEditor(Integer.class, true));
	this.defaultEditors.put(long.class, new CustomNumberEditor(Long.class, false));
	this.defaultEditors.put(Long.class, new CustomNumberEditor(Long.class, true));
	this.defaultEditors.put(float.class, new CustomNumberEditor(Float.class, false));
	this.defaultEditors.put(Float.class, new CustomNumberEditor(Float.class, true));
	this.defaultEditors.put(double.class, new CustomNumberEditor(Double.class, false));
	this.defaultEditors.put(Double.class, new CustomNumberEditor(Double.class, true));
	this.defaultEditors.put(BigDecimal.class, new CustomNumberEditor(BigDecimal.class, true));
	this.defaultEditors.put(BigInteger.class, new CustomNumberEditor(BigInteger.class, true));
    
	// Only register config value editors if explicitly requested.
	if (this.configValueEditorsActive) {
		StringArrayPropertyEditor sae = new StringArrayPropertyEditor();
		this.defaultEditors.put(String[].class, sae);
		this.defaultEditors.put(short[].class, sae);
		this.defaultEditors.put(int[].class, sae);
		this.defaultEditors.put(long[].class, sae);
	}
}

4.4> 添加ApplicationContextAwareProcessor处理器

下面我们继续来分析prepareBeanFactory(...)方法中的源码，如下所示：

【解释】在上面的源码红框中，只是将ApplicationContextAwareProcessor实例对象添加到了beanFactory的后置处理器集合中（即：List<BeanPostProcessor> beanPostProcessors）。

那既然ApplicationContextAwareProcessor是后置处理器，那它必然就已经实现了BeanPostProcessor接口。那么问题来了，后置处理器会在什么时候被Spring调用呢？ 这个问题在前面章节的 bean实例化 过程中其实已经介绍过了，我们再来回顾一下。请见下图所示：

【解释】在bean实例化的时候，也就是在Spring调用init-method方法的前后，会分别调用所有实现了BeanPostProcessor接口的实现类的postProcessBeforeInitialization(...)方法和postProcessAfterInitialization(...)方法。那么，下面我们就来看一下ApplicationContextAwareProcessor是如何自定义这两个方法的具体逻辑的。

ApplicationContextAwareProcessor的postProcessAfterInitialization(...)方法没有做特殊逻辑处理，采用的就是它父接口BeanPostProcessor中默认的方法实现。源码如下所示：

default Object postProcessAfterInitialization(Object bean, String beanName) throws BeansException {
	return bean;
}

ApplicationContextAwareProcessor的postProcessBeforeInitialization(...)方法做了自定义的实现，源码如下所示：

public Object postProcessBeforeInitialization(Object bean, String beanName) throws BeansException {
    // 只针对如下7种xxxAware进行特殊处理
	if (!(bean instanceof EnvironmentAware || bean instanceof EmbeddedValueResolverAware ||
			bean instanceof ResourceLoaderAware || bean instanceof ApplicationEventPublisherAware ||
			bean instanceof MessageSourceAware || bean instanceof ApplicationContextAware ||
			bean instanceof ApplicationStartupAware)) return bean;
	... ...
    invokeAwareInterfaces(bean); // 为7种xxxAware设置对应的资源
	... ...
	return bean;
}
private void invokeAwareInterfaces(Object bean) {
	if (bean instanceof EnvironmentAware) 
		((EnvironmentAware) bean).setEnvironment(this.applicationContext.getEnvironment());
	if (bean instanceof EmbeddedValueResolverAware) 
		((EmbeddedValueResolverAware) bean).setEmbeddedValueResolver(this.embeddedValueResolver);
	if (bean instanceof ResourceLoaderAware) 
		((ResourceLoaderAware) bean).setResourceLoader(this.applicationContext);
	if (bean instanceof ApplicationEventPublisherAware) 
		((ApplicationEventPublisherAware) bean).setApplicationEventPublisher(this.applicationContext);
	if (bean instanceof MessageSourceAware) 
		((MessageSourceAware) bean).setMessageSource(this.applicationContext);
	if (bean instanceof ApplicationStartupAware) 
		((ApplicationStartupAware) bean).setApplicationStartup(this.applicationContext.getApplicationStartup());
	if (bean instanceof ApplicationContextAware) 
		((ApplicationContextAware) bean).setApplicationContext(this.applicationContext);
}

【解释】通过上面的源码，我们可以发现，在后置处理方法中，只是针对7种Aware实现设置了它们所需的资源。

4.5> 设置忽略依赖

我们继续来分析prepareBeanFactory(...)方法中如下红框的内容。在4.3中我们当通过调用ApplicationContextAwareProcessor类的invokeAwareInterfaces()方法之后，7种xxxAware类型bean就都已经处理完毕了，那么下面的依赖注入操作就不需要再处理这些xxxAware类了。所以在如下红框种就对这7种Aware类执行了忽略依赖操作。

4.6> 注册依赖

下面我们再来继续分析prepareBeanFactory(...)方法中如下红框的内容。这部分内容是，当注册了依赖解析后，例如当注册了对BeanFactory.class的解析依赖后，当bean的属性注入的时候，一旦检测到属性为BeanFactory类型便会将beanFactory的实例注入进去。

五、invokeBeanFactoryPostProcessors(...)激活各种BeanFactory的后置处理器

下面我们来分析refresh()方法中的invokeBeanFactoryPostProcessors(beanFactory)这段代码的含义之前，通过方法名称，我们可以猜到这段方法是用来处理BeanFactoryPostProcessor的，那么 它具体是做什么的呢？ 请见如下源码所示：

@FunctionalInterface
public interface BeanFactoryPostProcessor {
	void postProcessBeanFactory(ConfigurableListableBeanFactory beanFactory) throws BeansException;
}

【解释】BeanFactoryPostProcessor接口跟BeanPostProcessor类似，都可以对bean的定义（即：配置的元数据）进行处理。也就是说，**Spring允许BeanFactoryPostProcessor在容器实际实例化任何其他的bean之前读取配置元数据，并进行修改。**如果配置多个BeanFactoryPostProcessor，可以通过实现Ordered接口来控制执行次序。

如果你想改变实际的bean实例，那么最好使用BeanPostProcessor。因为BeanFactoryPostProcessor的作用域范围是容器级别的。它只和你所使用的容器有关。它不会对定义在另一个容器中的bean进行后置处理。

那么，我们先不着急解析invokeBeanFactoryPostProcessors(beanFactory)这段源码的具体逻辑，我们先插播一条“娱乐新闻”，即：如何去使用BeanFactoryPostProcessor？

5.1> PropertySourcesPlaceholderConfigurer�的应用

在某个路径下创建一个配置文件，我们以prop/common.properties为例，在该文件内配置相应的属性值。

然后创建message的Bean配置信息，变量引用：${message.msg}。表明在其他的配置文件中指定了message.msg的值。那到底是哪个配置文件呢？我们创建PropertySourcesPlaceholderConfigurer的Bean配置信息。通过locations属性，来指定配置文件所在路径。

从IOC中获取message的bean实例对象，然后输出msg的值。

在上面的演示中，我们可以看到虽然在配置PropertySourcesPlaceholderConfigurer的Bean时指定了common.properties的文件路径，但是这个文件是什么时候被加载解析的呢？ 答案是：PropertySourcesPlaceholderConfigurer其实就是一种BeanFactoryPostProcessor，那么当Spring加载任何实现了这个接口的bean的配置时，都会在bean工厂载入所有bean的配置之后执行postProcessBeanFactory(beanFactory)方法。类的继承关系图请见下图所示：

本节开篇就说了，BeanFactoryPostProcessor接口只有一个方法，即：postProcessBeanFactory(beanFactory)，那么下面我们来看一下PropertySourcesPlaceholderConfigurer类是怎么实现的这个方法：

那么当配置文件信息被加载到了内存中后，就可以通过message.msg所配置的“Hello World!”值来替换${message.msg}了。此处替换流程暂且不深究。下面我们来看看如何自己实现一个BeanFactoryPostProcessor。

5.2> 自定义BeanFactoryPostProcessor的应用

实现接口BeanFactoryPostProcessor，创建自定义处理类。在postProcessBeanFactory�(beanFactory)方法中实现垃圾话过滤逻辑。需要注意的是，这个过滤垃圾话的作用域是针对容器内所有的bean的。

配置Bean，设置需要过滤的垃圾话列表。

获取allMessage的bean实例，验证msg中的垃圾话是否被过滤掉了。

5.3> 激活BeanFactoryPostProcessor源码解析

5.3.1> 源码注释解析

通过上面的示例，我们基本了解到了BeanFactoryPostProcessor是如何使用的。那么，下面我们还是回到refresh()方法中，看一下invokeBeanFactoryPostProcessors(beanFactory)这段代码的具体实现逻辑：

invokeBeanFactoryPostProcessors(beanFactory)方法的源码如下所示：

protected void invokeBeanFactoryPostProcessors(ConfigurableListableBeanFactory beanFactory) {
    // 激活BeanFactoryPostProcessor操作
	PostProcessorRegistrationDelegate.invokeBeanFactoryPostProcessors(beanFactory, getBeanFactoryPostProcessors());
	
	if (!NativeDetector.inNativeImage() && beanFactory.getTempClassLoader() == null 
        && beanFactory.containsBean(LOAD_TIME_WEAVER_BEAN_NAME)) {
		beanFactory.addBeanPostProcessor(new LoadTimeWeaverAwareProcessor(beanFactory));
		beanFactory.setTempClassLoader(new ContextTypeMatchClassLoader(beanFactory.getBeanClassLoader()));
	}
}

激活的实际逻辑代码就在invokeBeanFactoryPostProcessors(...)方法中，里面逻辑很多，我们先看这个方法的源码和注释，然后我们在下面内容中，抽取重要的内容再详细的讨论。

public static void invokeBeanFactoryPostProcessors(ConfigurableListableBeanFactory beanFactory, 
                                                 List<BeanFactoryPostProcessor> beanFactoryPostProcessors) {
	Set<String> processedBeans = new HashSet<>(); // 用于存储已经处理过的处理器名称
    
    /** 步骤1：对BeanDefinitionRegistry类型进行处理，包括【硬编码】+【配置方式】 */
	if (beanFactory instanceof BeanDefinitionRegistry) {
		BeanDefinitionRegistry registry = (BeanDefinitionRegistry) beanFactory; 
		List<BeanFactoryPostProcessor> regularPostProcessors = new ArrayList<>(); // 通过【硬编码】注册的BeanFactoryPostProcessor
		List<BeanDefinitionRegistryPostProcessor> registryProcessors = new ArrayList<>(); // 通过【硬编码】注册的BeanDefinitionRegistryPostProcessor

        /** 步骤1.1：遍历所有通过【硬编码】设置的BeanFactoryPostProcessor，按类型执行“分堆”操作，调用其postProcessBeanDefinitionRegistry(registry)方法 */
		for (BeanFactoryPostProcessor postProcessor : beanFactoryPostProcessors) {
			if (postProcessor instanceof BeanDefinitionRegistryPostProcessor) { 
				BeanDefinitionRegistryPostProcessor registryProcessor = (BeanDefinitionRegistryPostProcessor) postProcessor;
                registryProcessor.postProcessBeanDefinitionRegistry(registry); // BeanDefinitionRegistryPostProcessor接口中的方法，对BeanDefinitionRegistry执行后置处理
				registryProcessors.add(registryProcessor); // 通过【硬编码】注册的BeanDefinitionRegistryPostProcessor，会被放到registryProcessors中
			} else {
				regularPostProcessors.add(postProcessor); // 通过【硬编码】注册的其它BeanFactoryPostProcessor，会被放到regularPostProcessors中
			}
		}

        /** 步骤1.2：处理所有通过【配置方式】注册且实现了”PriorityOrdered接口“的BeanDefinitionRegistryPostProcessor实例集合，调用其postProcessBeanDefinitionRegistry(registry)方法 */
		List<BeanDefinitionRegistryPostProcessor> currentRegistryProcessors = new ArrayList<>();
		String[] postProcessorNames = beanFactory.getBeanNamesForType(BeanDefinitionRegistryPostProcessor.class, true, false);
		for (String ppName : postProcessorNames) {
			if (beanFactory.isTypeMatch(ppName, PriorityOrdered.class)) { // 如果实现了PriorityOrdered接口，则进行排序
				currentRegistryProcessors.add(beanFactory.getBean(ppName, BeanDefinitionRegistryPostProcessor.class));
				processedBeans.add(ppName);
			}
		}
		sortPostProcessors(currentRegistryProcessors, beanFactory); // 排序
		registryProcessors.addAll(currentRegistryProcessors); // 合并【硬编码】和【配置方式（且实现了PriorityOrdered接口）】的BeanDefinitionRegistryPostProcessor集合
		// 调用所有currentRegistryProcessors实例的postProcessBeanDefinitionRegistry(registry)方法，实现对registry的后置处理
        invokeBeanDefinitionRegistryPostProcessors(currentRegistryProcessors, registry, beanFactory.getApplicationStartup());
		currentRegistryProcessors.clear();

        /** 步骤1.3：处理所有通过【配置方式】注册且实现了”Ordered接口“的BeanDefinitionRegistryPostProcessor实例集合，调用其postProcessBeanDefinitionRegistry(registry)方法 */
		postProcessorNames = beanFactory.getBeanNamesForType(BeanDefinitionRegistryPostProcessor.class, true, false);
		for (String ppName : postProcessorNames) {
			if (!processedBeans.contains(ppName) && beanFactory.isTypeMatch(ppName, Ordered.class)) { // 如果实现了Ordered接口，则进行排序
				currentRegistryProcessors.add(beanFactory.getBean(ppName, BeanDefinitionRegistryPostProcessor.class));
				processedBeans.add(ppName);
			}
		}
		sortPostProcessors(currentRegistryProcessors, beanFactory); // 排序
		registryProcessors.addAll(currentRegistryProcessors); // 合并【硬编码】和【配置方式（且实现了Ordered接口）】的BeanDefinitionRegistryPostProcessor集合
		invokeBeanDefinitionRegistryPostProcessors(currentRegistryProcessors, registry, beanFactory.getApplicationStartup());
		currentRegistryProcessors.clear();

        /** 步骤1.4：处理所有通过【配置方式】注册且实现了BeanDefinitionRegistryPostProcessor实例集合（排除实现Ordered接口和PriorityOrdered接口），调用其postProcessBeanDefinitionRegistry(registry)方法 */
		boolean reiterate = true;
		while (reiterate) {
			reiterate = false;
			postProcessorNames = beanFactory.getBeanNamesForType(BeanDefinitionRegistryPostProcessor.class, true, false);
			for (String ppName : postProcessorNames) {
				if (!processedBeans.contains(ppName)) {
					currentRegistryProcessors.add(beanFactory.getBean(ppName, BeanDefinitionRegistryPostProcessor.class));
					processedBeans.add(ppName);
					reiterate = true;
				}
			}
			sortPostProcessors(currentRegistryProcessors, beanFactory);
			registryProcessors.addAll(currentRegistryProcessors);
			invokeBeanDefinitionRegistryPostProcessors(currentRegistryProcessors, registry, beanFactory.getApplicationStartup());
			currentRegistryProcessors.clear();
		}

        /** 步骤1.5：处理BeanDefinitionRegistryPostProcessor实例集合和BeanFactoryPostProcessor实例集合，调用其postProcessBeanFactory(beanFactory)方法 */
		invokeBeanFactoryPostProcessors(registryProcessors, beanFactory);
		invokeBeanFactoryPostProcessors(regularPostProcessors, beanFactory);
	}
        
    /** 步骤2：对ConfigurableListableBeanFactory而非BeanDefinitionRegistry类型进行处理【硬编码】+【配置方式】 ，调用其postProcessBeanFactory(beanFactory)方法*/
	else {
		invokeBeanFactoryPostProcessors(beanFactoryPostProcessors, beanFactory);
	}

	String[] postProcessorNames =
			beanFactory.getBeanNamesForType(BeanFactoryPostProcessor.class, true, false);
	List<BeanFactoryPostProcessor> priorityOrderedPostProcessors = new ArrayList<>();
	List<String> orderedPostProcessorNames = new ArrayList<>();
	List<String> nonOrderedPostProcessorNames = new ArrayList<>();
	for (String ppName : postProcessorNames) {
		if (processedBeans.contains(ppName)) // skip - already processed in first phase above
		else if (beanFactory.isTypeMatch(ppName, PriorityOrdered.class)) // 如果实现了PriorityOrdered接口，则进行排序
			priorityOrderedPostProcessors.add(beanFactory.getBean(ppName, BeanFactoryPostProcessor.class));
		else if (beanFactory.isTypeMatch(ppName, Ordered.class)) // 如果实现了Ordered接口，则进行排序
			orderedPostProcessorNames.add(ppName);
		else 
			nonOrderedPostProcessorNames.add(ppName); // 否则，不排序了
	}

    /** 步骤3：对ConfigurableListableBeanFactory类型并且实现了”PriorityOrdered接口“的进行处理【配置方式】 ，调用其postProcessBeanFactory(beanFactory)方法*/
	sortPostProcessors(priorityOrderedPostProcessors, beanFactory);
	invokeBeanFactoryPostProcessors(priorityOrderedPostProcessors, beanFactory);
    List<BeanFactoryPostProcessor> orderedPostProcessors = new ArrayList<>(orderedPostProcessorNames.size());
	for (String postProcessorName : orderedPostProcessorNames) {
		orderedPostProcessors.add(beanFactory.getBean(postProcessorName, BeanFactoryPostProcessor.class));
	}

    /** 步骤4：对ConfigurableListableBeanFactory类型并且实现了”Ordered接口“的进行处理【配置方式】 ，调用其postProcessBeanFactory(beanFactory)方法*/
	sortPostProcessors(orderedPostProcessors, beanFactory);
	invokeBeanFactoryPostProcessors(orderedPostProcessors, beanFactory);
    List<BeanFactoryPostProcessor> nonOrderedPostProcessors = new ArrayList<>(nonOrderedPostProcessorNames.size());
	for (String postProcessorName : nonOrderedPostProcessorNames) {
		nonOrderedPostProcessors.add(beanFactory.getBean(postProcessorName, BeanFactoryPostProcessor.class));
	}

    /** 步骤5：对ConfigurableListableBeanFactory类型并且没有实现（PriorityOrdered接口或Ordered接口）进行处理【配置方式】 ，调用其postProcessBeanFactory(beanFactory)方法*/
	invokeBeanFactoryPostProcessors(nonOrderedPostProcessors, beanFactory);
	beanFactory.clearMetadataCache();
}

通过上面的源码和源码注释，我们可以看到，其实就是针对两种情况进行分别的后置处理：

【情况1】一个类实现了ConfigurableListableBeanFactory接口 + BeanDefinitionRegistry接口 【情况2】一个类仅实现了ConfigurableListableBeanFactory接口

而对于后置处理器来说，有如下对应的处理关系：

【针对BeanDefinitionRegistry接口】我们采用BeanDefinitionRegistryPostProcessor后置处理器进行增强操作。 【针对ConfigurableListableBeanFactory接口】我们采用BeanFactoryPostProcessor后置处理器进行增强操作。

而由于BeanDefinitionRegistryPostProcessor继承了BeanFactoryPostProcessor，所以要区别处理：

5.3.2> 整体流程概述

找出实现了BeanDefinitionRegistry接口 + ConfigurableListableBeanFactory接口的bean

【步骤1】调用“硬编码”设置的BeanDefinitionRegistryPostProcessor的postProcessBeanDefinitionRegistry(registry)方法进行增强； 【步骤2】调用“配置方式”设置的BeanDefinitionRegistryPostProcessor并实现了PriorityOrdered接口的postProcessBeanDefinitionRegistry(registry)方法进行增强； 【步骤3】调用“配置方式”设置的BeanDefinitionRegistryPostProcessor并实现了Ordered接口的postProcessBeanDefinitionRegistry(registry)方法进行增强； 【步骤4】调用“配置方式”设置的BeanDefinitionRegistryPostProcessor没有实现排序接口的postProcessBeanDefinitionRegistry(registry)方法进行增强； 【步骤5】调用“硬编码”BeanDefinitionRegistryPostProcessor的postProcessBeanFactory(beanFactory)方法进行增强； 【步骤6】调用“硬编码”BeanFactoryPostProcessor的postProcessBeanFactory(beanFactory)方法进行增强；

找出仅仅实现了ConfigurableListableBeanFactory接口的bean

【步骤1】调用“硬编码”设置BeanFactoryPostProcessor的postProcessBeanFactory(beanFactory)方法进行增强； 【步骤2】调用“配置方式”设置的BeanFactoryPostProcessor并实现了PriorityOrdered接口的postProcessBeanFactory(beanFactory)方法进行增强； 【步骤3】调用“配置方式”设置的BeanFactoryPostProcessor并实现了Ordered接口的postProcessBeanFactory(beanFactory)方法进行增强； 【步骤4】调用“配置方式”设置的BeanFactoryPostProcessor没有实现排序接口的postProcessBeanFactory(beanFactory)方法进行增强；

那么，什么样的类即实现BeanDefinitionRegistry接口又实现ConfigurableListableBeanFactory接口呢？ 我们以DefaultListableBeanFactory为例，它就是既实现了ConfigurableListableBeanFactory接口，也实现了BeanDefinitionRegistry接口。如下所示：

那么 上面所说的【硬编码】，又是从哪里写入的呢？ 我们可以看到在 AbstractApplicationContext 类中有addBeanFactoryPostProcessor(postProcessor)方法，通过它，我们就可以采用硬编码的方式添加PostProcessor了。

为了更便于大家对整个流程的理解，如下我提供了针对整体处理流程的图解。

5.3.3> 整体流程图解

针对实现了BeanDefinitionRegistry接口 + ConfigurableListableBeanFactory接口 的bean，调用BeanDefinitionRegistryPostProcessor 类的postProcessBeanDefinitionRegistry�(registry)方法的后置处理

针对实现了BeanDefinitionRegistry接口 + ConfigurableListableBeanFactory接口 的bean，调用 BeanFactoryPostProcessor 类的postProcessBeanFactory(beanFactory)方法的后置处理

针对仅仅实现了ConfigurableListableBeanFactory接口的bean，调用BeanFactoryPostProcessor类的postProcessBeanFactory(beanFactory)方法的后置处理

六、registerBeanPostProcessors(...)注册各种Bean的后置处理器

6.1> 使用示例

创建一个BeanPostProcessor的实现类——MuseBeanPostProcessor.java

在oldbean.xml配置文件中注册MuseBeanPostProcessor后置处理器。

启动项目，我们发现当使用ApplicationContext加载bean的时候，就可以调用我们创建的后置处理器；但是如果使用XmlBeanFactory加载bean，却无法调用我们创建的后置处理器。

其实这也印证了ApplicationContext是BeanFactory的加强版本，即：Plus版本。在Spring中，其实绝大部分的功能都是通过后置处理器的方式进行扩展的，而BeanFactory其实只是初始化IOC容器了，并没有实现后置处理器的自动注册功能。

而ApplicationContext实现了自动添加后置处理器的能力，所以才会通过调用applicationContext.getBean("allMessage")的方式输出了“-------allMessage---------”，而通过beanFactory.getBean("allMessage")的方式却没有输出。

6.2> 源码解析

我们了解了怎样去使用BeanPostProcessor之后，下面我们来看一下涉及到注册BeanPostProcessor的逻辑代码，如下所示：

如下是最核心的BeanPostProcessor方法，这里面的逻辑与BeanFactoryPostProcessor类似，请见如下源码和注释：

public static void registerBeanPostProcessors(ConfigurableListableBeanFactory beanFactory, AbstractApplicationContext applicationContext) {
	String[] postProcessorNames = beanFactory.getBeanNamesForType(BeanPostProcessor.class, true, false);
	
    // BeanPostProcessorChecker是一个用于检查操作的后置处理器，即：当Spring配置中的后处理器还没有被注册就已经开始了bean的初始化是，那么Checker就会打印提示信息日志
    int beanProcessorTargetCount = beanFactory.getBeanPostProcessorCount() + 1 + postProcessorNames.length;
	beanFactory.addBeanPostProcessor(new BeanPostProcessorChecker(beanFactory, beanProcessorTargetCount));

	List<BeanPostProcessor> priorityOrderedPostProcessors = new ArrayList<>();
	List<BeanPostProcessor> internalPostProcessors = new ArrayList<>();
	List<String> orderedPostProcessorNames = new ArrayList<>();
	List<String> nonOrderedPostProcessorNames = new ArrayList<>();
	for (String ppName : postProcessorNames) {
		if (beanFactory.isTypeMatch(ppName, PriorityOrdered.class)) { // 存储实现了PriorityOrdered接口的后置处理器
			BeanPostProcessor pp = beanFactory.getBean(ppName, BeanPostProcessor.class); 
			priorityOrderedPostProcessors.add(pp);
			if (pp instanceof MergedBeanDefinitionPostProcessor) 
				internalPostProcessors.add(pp); // 存储实现了PriorityOrdered接口并且是MergedBeanDefinitionPostProcessor类型后置处理器
		}
		else if (beanFactory.isTypeMatch(ppName, Ordered.class)) 
			orderedPostProcessorNames.add(ppName); // 存储实现了Ordered接口的后置处理器
		else 
			nonOrderedPostProcessorNames.add(ppName); // 存储未实现排序接口的后置处理器
	}
	sortPostProcessors(priorityOrderedPostProcessors, beanFactory);
	registerBeanPostProcessors(beanFactory, priorityOrderedPostProcessors);
	
    List<BeanPostProcessor> orderedPostProcessors = new ArrayList<>(orderedPostProcessorNames.size());
	for (String ppName : orderedPostProcessorNames) {
		BeanPostProcessor pp = beanFactory.getBean(ppName, BeanPostProcessor.class);
		orderedPostProcessors.add(pp);
		if (pp instanceof MergedBeanDefinitionPostProcessor) {
			internalPostProcessors.add(pp); // 存储实现了Ordered接口并且是MergedBeanDefinitionPostProcessor类型后置处理器
		}
	}
	sortPostProcessors(orderedPostProcessors, beanFactory);
	registerBeanPostProcessors(beanFactory, orderedPostProcessors);

    List<BeanPostProcessor> nonOrderedPostProcessors = new ArrayList<>(nonOrderedPostProcessorNames.size());
	for (String ppName : nonOrderedPostProcessorNames) {
		BeanPostProcessor pp = beanFactory.getBean(ppName, BeanPostProcessor.class);
		nonOrderedPostProcessors.add(pp);
		if (pp instanceof MergedBeanDefinitionPostProcessor) {
			internalPostProcessors.add(pp); // 存储没有实现排序接口并且是MergedBeanDefinitionPostProcessor类型后置处理器
		}
	}
	registerBeanPostProcessors(beanFactory, nonOrderedPostProcessors);

    // 注册MergedBeanDefinitionPostProcessor类型后置处理器
	sortPostProcessors(internalPostProcessors, beanFactory);
	registerBeanPostProcessors(beanFactory, internalPostProcessors);
    
	beanFactory.addBeanPostProcessor(new ApplicationListenerDetector(applicationContext));
}

【步骤1】针对实现了PriorityOrdered接口的BeanPostProcessor后置处理器执行排序和注册操作。 【步骤2】针对实现了Ordered接口的BeanPostProcessor后置处理器执行排序和注册操作。 【步骤3】针对没有实现排序接口的BeanPostProcessor后置处理器执行注册操作。 【步骤4】针对MergedBeanDefinitionPostProcessor类型的后置处理器执行注册操作。

在调用registerBeanPostProcessors(...)方法时，不用担心重复注册问题，因为都是先执行remove再执行add的，如下所示：

七、initMessageSource()为上下文初始化消息源

Spring国际化是根据客户端的系统语言类型返回对应的界面，这个便是所谓的i18n国际化（internationalization）。

国际化信息也称之为本地化信息，需要两个条件来最终决定：

【条件1】语言类型（eg：中文） 【条件2】国家/地区的类型（ge：中国大陆、中国台湾、中国香港、新加坡、马来西亚……）

在JDK中，提供了java.util.Locale类用来支持国际化信息，它提供了如下使用方式：

【方式1】指定语言和国家/地区——new Locale("zh", "CN") 或 Locale.CHINA 【方式2】指定语言——new Locale("zh") 或 Locale.CHINESE 【方式3】根据操作系统默认语言设置——Locale.getDefault()

MessageSource是负责国际化信息的接口，它有如下几个重要实现类：

ResourceBundleMessageSource：允许通过资源名加载国际化资源。 ReloadableResourceBundleMessageSource：与ResourceBundleMessageSource功能相似，额外提供定时刷新功能，不用重启系统，即可更新资源信息。 StaticMessageSource：主要用于程序测试，允许通过编程的方式提供国际化信息。 DelegatingMessageSource：为方便操作MessageSource的代理类。

7.1> 使用示例

创建i18n_zh.properties文件，里面添加“hello=你好！世界！”，然后通过 native2ascii 将其转化为utf8的ASCII编码文件。

创建i18n_en.properties文件，里面添加“hello=Hello World！”，然后将i18n_zh.properties和i18n_en.properties都放入到muse文件夹下。如下所示：

在配置文件oldbean.xml中配置国际化支持，其中bean id必须是“messageSource”，否则就会报NoSuchMessageException异常

执行测试代码：

7.2> 源码解析

了解了怎么使用国际化信息之后，我们现在来看一下初始化国际化资源的代码逻辑，如下图红框所示：

那么，在initMessageSource()方法中，通过判断是自定义国际化资源还是默认国际化资源，创建MessageSource实现类，然后赋值给AbstractApplicationContext的全局变量messageSource。

protected void initMessageSource() {
	ConfigurableListableBeanFactory beanFactory = getBeanFactory();
    // 如果需要用户自定义国际化资源，则需要创建一个bean的id必须是“messageSource”（硬编码）的bean
	if (beanFactory.containsLocalBean(MESSAGE_SOURCE_BEAN_NAME)) { 
		this.messageSource = beanFactory.getBean(MESSAGE_SOURCE_BEAN_NAME, MessageSource.class); // 赋值给全局变量messageSource
		if (this.parent != null && this.messageSource instanceof HierarchicalMessageSource) {
			HierarchicalMessageSource hms = (HierarchicalMessageSource) this.messageSource;
			if (hms.getParentMessageSource() == null) {
				hms.setParentMessageSource(getInternalParentMessageSource());
			}
		}
	}
	// 否则，使用DelegatingMessageSource，一般后续通过调用getMessage方法返回国际化资源
	else {
		DelegatingMessageSource dms = new DelegatingMessageSource();
		dms.setParentMessageSource(getInternalParentMessageSource());
		this.messageSource = dms; // 赋值给全局变量messageSource
		beanFactory.registerSingleton(MESSAGE_SOURCE_BEAN_NAME, this.messageSource);
	}
}

protected MessageSource getInternalParentMessageSource() {
	return (getParent() instanceof AbstractApplicationContext ?
        ((AbstractApplicationContext) getParent()).messageSource : getParent());
}

public ApplicationContext getParent() {
	return this.parent;
}

在使用时，我们通过调用applicationContext.getMessage("hello", null, Locale.US)来获取国际化信息，那么我们看一下getMessage(...)方法的源码是怎么处理的：

public String getMessage(String code, @Nullable Object[] args, Locale locale) throws NoSuchMessageException {
	return getMessageSource().getMessage(code, args, locale);
}

private MessageSource getMessageSource() throws IllegalStateException {
	if (this.messageSource == null) 
		throw new IllegalStateException("MessageSource not initialized - call 'refresh' before accessing messages via the context: " + this);
	return this.messageSource; // 就是从全局messageSource中获取的国际化资源
}

八、initApplicationEventMulticaster()为上下文初始化应用事件广播器

8.1> 使用示例

首先，继承ApplicationEvent，实现自定义ApplicationEvent——MuseApplicationEvent：

其次，实现ApplicationListener接口，实现自定义ApplicationListener——MuseApplicationListener：

将自定义应用监听器MuseApplicationListener注册倒IOC中：

测试发布一个MuseApplicationEvent类型的事件，查看控制台输出内容：

8.2> 源码解析

好了，我们通过刚刚的示例，了解到了如何使用应用事件发起广播，那么下面我们就来看一下源码中如何进行初始化操作的，在下图refresh()方法的红框中：

我们再来看initApplicationEventMulticaster()方法的具体处理逻辑：

protected void initApplicationEventMulticaster() {
	ConfigurableListableBeanFactory beanFactory = getBeanFactory();
    // 如果用户【自定义】了EventMulticaster，则向Spring中注册用户自定义的事件广播器
	if (beanFactory.containsLocalBean(APPLICATION_EVENT_MULTICASTER_BEAN_NAME)) {
		this.applicationEventMulticaster = beanFactory.getBean(APPLICATION_EVENT_MULTICASTER_BEAN_NAME, ApplicationEventMulticaster.class);
	}
    // 如果用户【没有自定义】EventMulticaster，则向Spring中注册默认的SimpleApplicationEventMulticaster广播器
	else {
		this.applicationEventMulticaster = new SimpleApplicationEventMulticaster(beanFactory);
		beanFactory.registerSingleton(APPLICATION_EVENT_MULTICASTER_BEAN_NAME, this.applicationEventMulticaster);
	}
}

上面的代码逻辑也是比较简单清晰的，就执行了两个判断逻辑： 【判断1】如果用户自定义了EventMulticaster，则向Spring中注册用户自定义的事件广播器。 【判断2】如果用户没有自定义EventMulticaster，则向Spring中注册默认的SimpleApplicationEventMulticaster广播器。

那么，我们在看一下SimpleApplicationEventMulticaster中是怎么处理广播事件的：

public void multicastEvent(ApplicationEvent event) {
	multicastEvent(event, resolveDefaultEventType(event));
}
public void multicastEvent(final ApplicationEvent event, @Nullable ResolvableType eventType) {
	ResolvableType type = (eventType != null ? eventType : resolveDefaultEventType(event));
	Executor executor = getTaskExecutor();
	for (ApplicationListener<?> listener : getApplicationListeners(event, type)) {
		if (executor != null) 
			executor.execute(() -> invokeListener(listener, event)); // 采用并行方式执行广播操作
		else 
			invokeListener(listener, event); // 采用串行方式执行广播操作
	}
}

protected void invokeListener(ApplicationListener<?> listener, ApplicationEvent event) {
	ErrorHandler errorHandler = getErrorHandler();
	if (errorHandler != null) 
		try {
			doInvokeListener(listener, event); // 触发广播监听行为
		}catch (Throwable err) {errorHandler.handleError(err);}
	else 
		doInvokeListener(listener, event); // 触发广播监听行为
}

private void doInvokeListener(ApplicationListener listener, ApplicationEvent event) {
	try {
		listener.onApplicationEvent(event); // 发送监听事件
	}catch (ClassCastException ex) {...}
}

从上面的代码中，我们可以看出核心的逻辑就是两个步骤： 【步骤1】通过getApplicationListeners(event, type)方法获得所有的应用监听器列表。 【步骤2】遍历调用每一个ApplicationListener的onApplicationEvent(event)方法来发送监听事件。

需要注意的一点就是，当产生Spring监听事件的时候，对于每一个监听器来说，其实他们都可以获得所有产生的监听事件，那么具体处理哪一种类型的监听事件，可以在监听器中进行逻辑处理（如：上面8.1使用示例中的MuseApplicationListener实现方式）。当然，我们也可以通过使用泛型来约束处理的监听事件类型。如下图所示，那么MuseApplicationListener就只能处理MuseApplicationEvent类型的事件了。

九、registerListeners()注册监听器

注册监听器的理解代码如下所示：

下面我们再来详细看一下registerListeners()方法的具体逻辑：

protected void registerListeners() {
    /** 添加以【硬编码】方式注册的监听器 */
    for (ApplicationListener<?> listener : getApplicationListeners()) 
    	getApplicationEventMulticaster().addApplicationListener(listener);

	/** 添加以【配置文件】方式注册的监听器 */
	String[] listenerBeanNames = getBeanNamesForType(ApplicationListener.class, true, false);
	for (String listenerBeanName : listenerBeanNames) 
	    getApplicationEventMulticaster().addApplicationListenerBean(listenerBeanName);
    
	/** 发送在多播设置之前发布的ApplicationEvent事件 */
	Set<ApplicationEvent> earlyEventsToProcess = this.earlyApplicationEvents;
	this.earlyApplicationEvents = null;
	if (!CollectionUtils.isEmpty(earlyEventsToProcess)) 
	    for (ApplicationEvent earlyEvent : earlyEventsToProcess) 
	        getApplicationEventMulticaster().multicastEvent(earlyEvent);
}

注册监听器的方法也比较简单清晰，它一共做到了如下3个步骤： 【步骤1】添加以硬编码方式注册的监听器 【步骤2】添加以配置文件方式注册的监听器 【步骤3】发送在多播设置之前发布的ApplicationEvent事件

十、finishBeanFactoryInitialization(...)初始化非延迟加载单例

10.1> 概述

此处涉及到的就是我们完成了BeanFactory初始化工作之后的收尾工作了，包含：

【步骤1】为上下文添加ConversionService 【步骤2】为上下文添加EmbeddedValueResolver（嵌入值解析器） 【步骤3】初始化LoadTimeWeaverware类型的Bean 【步骤4】停止使用临时ClassLoader进行类型匹配 【步骤5】冻结配置 【步骤6】实例化所有剩余的（非惰性初始化）单例

10.2> 源码解析

我们来看一下负责这部分逻辑的代码：

具体的逻辑处理就是在finishBeanFactoryInitialization(beanFactory)的方法中，如下所示：

protected void finishBeanFactoryInitialization(ConfigurableListableBeanFactory beanFactory) {
	/** 步骤1：为上下文初始化ConversionService */
	if (beanFactory.containsBean(CONVERSION_SERVICE_BEAN_NAME) && // 是否存在名称为“conversionService”并且类型是ConversionService的Bean
			beanFactory.isTypeMatch(CONVERSION_SERVICE_BEAN_NAME, ConversionService.class)) 
		beanFactory.setConversionService(beanFactory.getBean(CONVERSION_SERVICE_BEAN_NAME, ConversionService.class));

	/** 步骤2：如果没有设置EmbeddedValueResolver（嵌入值解析器），则默认添加一个StringValueResolver */
	if (!beanFactory.hasEmbeddedValueResolver()) 
		beanFactory.addEmbeddedValueResolver(strVal -> getEnvironment().resolvePlaceholders(strVal));
	
	/** 步骤3：尽早初始化LoadTimeWeaverware类型的Bean，以便尽早注册其转换器 */
	String[] weaverAwareNames = beanFactory.getBeanNamesForType(LoadTimeWeaverAware.class, false, false);
	for (String weaverAwareName : weaverAwareNames) 
		getBean(weaverAwareName);
	
	beanFactory.setTempClassLoader(null); // 停止使用临时ClassLoader进行类型匹配
	beanFactory.freezeConfiguration(); // 冻结配置
	beanFactory.preInstantiateSingletons(); // 实例化所有剩余的（非惰性初始化）单例
}

冻结所有配置

public void freezeConfiguration() {
	this.configurationFrozen = true; // 开启配置冻结开关
	this.frozenBeanDefinitionNames = StringUtils.toStringArray(this.beanDefinitionNames);
}

初始化非延迟加载单例

public void preInstantiateSingletons() throws BeansException {
	List<String> beanNames = new ArrayList<>(this.beanDefinitionNames);
	/** 步骤1：初始化所有非惰性单例bean */
	for (String beanName : beanNames) {
		RootBeanDefinition bd = getMergedLocalBeanDefinition(beanName);
		if (!bd.isAbstract() && bd.isSingleton() && !bd.isLazyInit()) {
            // 针对FactoryBean创建bean
			if (isFactoryBean(beanName)) {
				Object bean = getBean(FACTORY_BEAN_PREFIX + beanName);
				if (bean instanceof FactoryBean) {
					FactoryBean<?> factory = (FactoryBean<?>) bean;
					boolean isEagerInit;
					if (System.getSecurityManager() != null && factory instanceof SmartFactoryBean) 
						isEagerInit = AccessController.doPrivileged((PrivilegedAction<Boolean>) ((SmartFactoryBean<?>) factory)::isEagerInit, getAccessControlContext());
					else 
						isEagerInit = (factory instanceof SmartFactoryBean && ((SmartFactoryBean<?>) factory).isEagerInit());
					if (isEagerInit) // 对于配置了【非惰性加载】的bean执行创建操作
						getBean(beanName);
				}
			} 
            // 针对非FactoryBean创建bean
			else getBean(beanName); 
		}
	}
	/** 步骤2：对于配置了SmartInitializingSingleton的Bean，触发初始化后回调（post-initialization callback）*/
	for (String beanName : beanNames) {
		Object singletonInstance = getSingleton(beanName);
        // 针对SmartInitializingSingleton类型触发初始化后回调，即：afterSingletonsInstantiated
		if (singletonInstance instanceof SmartInitializingSingleton) {
			SmartInitializingSingleton smartSingleton = (SmartInitializingSingleton) singletonInstance;
			if (System.getSecurityManager() != null) 
				AccessController.doPrivileged((PrivilegedAction<Object>) () -> {
					smartSingleton.afterSingletonsInstantiated(); // 触发初始化后回调
					return null;
				}, getAccessControlContext());
			else smartSingleton.afterSingletonsInstantiated(); // 触发初始化后回调
		}
	}
}

在上面代码中，总共执行了如下两个步骤： 【步骤1】步骤1：初始化所有非惰性（isEagerInit）单例bean。即：针对FactoryBean类型创建bean 和 针对其他类型创建bean； 【步骤2】对于配置了SmartInitializingSingleton的Bean，触发初始化后回调，即：调用afterSingletonsInstantiated()方法；

十一、finishRefresh()完成refresh操作

最后这部分，我们来看一下finishRefresh()方法的逻辑代码：

在finishRefresh()方法中，主要就是针对Lifecycle接口进行处理，该接口主要包含如下两个重要方法：

start() ：Spring启动的时候，调用该方法开始生命周期； stop() ：Spring关闭的时候，调用该方法结束生命周期；

那么下面我们来看一下在finishRefresh()方法中，它是如何实现这个功能的：

protected void finishRefresh() {
	clearResourceCaches(); // 仅执行清除缓存操作：resourceCaches.clear()
	initLifecycleProcessor(); // 初始化生命周期处理器
	getLifecycleProcessor().onRefresh(); // 启动所有实现了Lifecycle接口的bean
	publishEvent(new ContextRefreshedEvent(this)); // 发布上下文已刷新的事件
	if (!NativeDetector.inNativeImage()) // 判断是不是在GraalVM虚拟机上运行
		LiveBeansView.registerApplicationContext(this);
}

初始化生命周期处理器——LifecycleProcessor

protected void initLifecycleProcessor() {
	ConfigurableListableBeanFactory beanFactory = getBeanFactory();
    /** 步骤1：如果存在名字是“lifecycleProcessor”的生命周期处理器，则将其赋值给全局变量lifecycleProcessor */
	if (beanFactory.containsLocalBean(LIFECYCLE_PROCESSOR_BEAN_NAME)) {
		this.lifecycleProcessor = beanFactory.getBean(LIFECYCLE_PROCESSOR_BEAN_NAME, LifecycleProcessor.class);
        
    /** 步骤2：如果不存在，则创建默认的生命周期处理器——DefaultLifecycleProcessor，并赋值给全局变量lifecycleProcessor */
	else {
		DefaultLifecycleProcessor defaultProcessor = new DefaultLifecycleProcessor();
		defaultProcessor.setBeanFactory(beanFactory);
		this.lifecycleProcessor = defaultProcessor;
		beanFactory.registerSingleton(LIFECYCLE_PROCESSOR_BEAN_NAME, this.lifecycleProcessor);
	}
}

通过调用onRefresh()方法来启动所有实现了Lifecycle接口的bean

public void onRefresh() {
	startBeans(true); // 启动所有实现了Lifecycle接口的bean
	this.running = true;
}

private void startBeans(boolean autoStartupOnly) {
	Map<String, Lifecycle> lifecycleBeans = getLifecycleBeans(); // 获得所有Lifecycle集合
	Map<Integer, LifecycleGroup> phases = new TreeMap<>();

	/** 步骤1：如果autoStartupOnly是false，或者是SmartLifecycle类型的bean，并且其内部方法isAutoStartup()返回了true，则会保存到phase中 */
	lifecycleBeans.forEach((beanName, bean) -> {
		if (!autoStartupOnly || (bean instanceof SmartLifecycle && ((SmartLifecycle) bean).isAutoStartup())) {
			int phase = getPhase(bean);
			phases.computeIfAbsent(
					phase,
					p -> new LifecycleGroup(phase, this.timeoutPerShutdownPhase, lifecycleBeans, autoStartupOnly)
			).add(beanName, bean);
		}
	});

	/** 步骤2：如果phase中存在待启动的LifecycleGroup，则调用每一个start()方法 */
	if (!phases.isEmpty()) 
		phases.values().forEach(LifecycleGroup::start); // 调用LifecycleGroup的start()方法
}

最后我们发现，会调用到DefaultLifecycleProcessor的内部类LifecycleGroup的start()方法；然后在doStart()方法中最终调用了每一个实现了Lifecycle接口的子类的start()方法。

public void start() {
	if (this.members.isEmpty()) return;
	Collections.sort(this.members);
	for (LifecycleGroupMember member : this.members) 
		doStart(this.lifecycleBeans, member.name, this.autoStartupOnly); // 在Spring中，真正执行某个逻辑都是以do开头的
}

private void doStart(Map<String, ? extends Lifecycle> lifecycleBeans, String beanName, boolean autoStartupOnly) {
	Lifecycle bean = lifecycleBeans.remove(beanName);
	if (bean != null && bean != this) {
		String[] dependenciesForBean = getBeanFactory().getDependenciesForBean(beanName);
		for (String dependency : dependenciesForBean) 
			doStart(lifecycleBeans, dependency, autoStartupOnly); // 如果有嵌套，则通过递归处理
		
		if (!bean.isRunning() && (!autoStartupOnly || !(bean instanceof SmartLifecycle) || ((SmartLifecycle) bean).isAutoStartup())) {
			try {
				bean.start(); // 调用Lifecycle实现类的start()方法触发生命周期开始操作
			} catch (Throwable ex) {...}
		}
	}
}

今天的文章内容就这些了：

写作不易，笔者几个小时甚至数天完成的一篇文章，只愿换来您几秒钟的 点赞 & 分享 。

更多技术干货，欢迎大家关注公众号“爪哇缪斯” ~ \(^o^)/ ~ 「干货分享，每天更新」