调用过程复现：
在DefaultListableBeanFactory的registerBeanDefinition里打上断点，运行Entrance，观察调用栈：
Entrance源码：阅读Spring源码第一步：源码编译与创建调试入口
注册是从主函数开始的： 
之后进入到FileSystemXmlApplicationContext的构造函数：
public FileSystemXmlApplicationContext(String configLocation) throws BeansException {
this(new String[] { configLocation}, true, null);
}又调用了另外一个构造函数：
public FileSystemXmlApplicationContext(
String[] configLocations, boolean refresh, @Nullable ApplicationContext parent)
throws BeansException {
super(parent);
setConfigLocations(configLocations);
if (refresh) {
refresh();
}
}对应变量的值： 
其中configLocations是个数组，所以猜测最后调用了加载多个资源的方法。
又调用refresh()方法进行容器的初始化，此时又来到AbstractApplicationContext的refresh方法里： 
又调用了obtainFreshBeanFactory方法，跳进去会发现它是调用了子类的refreshBeanFactory方法，以刷新子类的容器
protected ConfigurableListableBeanFactory obtainFreshBeanFactory() {
refreshBeanFactory();
return getBeanFactory();
}再往前进会发现实现refreshBeanFactory方法的是AbstractRefreshableApplicationContext类： 
先创建了容器实例，再将实例传入到loadBeanDefinitions里
进入到loadBeanDefinitions，该方法是由AbstractXmlApplicationContext实现的：
protected void loadBeanDefinitions(DefaultListableBeanFactory beanFactory) throws BeansException, IOException {
// Create a new XmlBeanDefinitionReader for the given BeanFactory.
// 为给定的BeanFactory创建一个新的XmlBeanDefinitionReader
XmlBeanDefinitionReader beanDefinitionReader = new XmlBeanDefinitionReader(beanFactory);
// Configure the bean definition reader with this context's
// resource loading environment.
beanDefinitionReader.setEnvironment(this.getEnvironment());
// 将容器本身"献祭"
beanDefinitionReader.setResourceLoader(this);
beanDefinitionReader.setEntityResolver(new ResourceEntityResolver(this));
// Allow a subclass to provide custom initialization of the reader,
// then proceed with actually loading the bean definitions.
initBeanDefinitionReader(beanDefinitionReader);
loadBeanDefinitions(beanDefinitionReader);
}
先是定义了XmlBeanDefinitionReader的实例变量beanDefinitionReader，变量的构造函数便是传入的DefaultListableBeanFactory实例;
此外beanDefinitionReader还给自己的ResourceLoader设置上FileSystemXmlApplicationContext;
因此FileSystemXmlApplicationContext实例和DefaultListableBeanFactory实例便是通过beanDefinitionReader对象串联到了一起，这也就表明了打通了资源加载和BeanDefinition之间的通路。
再前进一步就是加载资源的配置流程了（AbstractXmlApplicationContext.java）：
protected void loadBeanDefinitions(XmlBeanDefinitionReader reader) throws BeansException, IOException {
Resource[] configResources = getConfigResources();
if (configResources != null) {
reader.loadBeanDefinitions(configResources);
}
String[] configLocations = getConfigLocations(); // 从这里继续进
if (configLocations != null) {
reader.loadBeanDefinitions(configLocations);
}
}进入到getConfigLocations方法里：
@Override
public int loadBeanDefinitions(String... locations) throws BeanDefinitionStoreException {
Assert.notNull(locations, "Location array must not be null");
int count = 0;
for (String location : locations) {
count += loadBeanDefinitions(location);
}
return count;
}这里就是根据location来逐个调用loadBeanDefinitions去加载。
继续进到loadBeanDefinitions方法里： 
可以看到确实是使用了ResourcePatternResolver来进行加载的，和上面的推断一样是用可以同时加载多个资源的。
再进入两层到loadBeanDefinitions方法里： 
发现到了对resource包裹上EncodedResource这一步
再进入一层，此时就是对资源进行编码处理了： 
进入到实际干活的doLoadBeanDefinitions中： 
这里面主要就是将xml解析成document对象了，解析完成之后就进入到注册阶段
注册阶段： 
先是将Document对象解析成一个个的BeanDifinitions 
继续进入到doRegisterBeanDefinitions里： 
就会发现这里开始解析BeanDefinition了，并且此处的delegate对象是BeanDefinitionParserDelegate对象
之后就会进入解析逻辑里面进行BeanDefinition的解析了： 
因为我们遵循的是xml定义的规范，所以会执行parseDefaultElement方法，方法之前已经分析过了，这一步会递归执行多次。
再往深一点就会看到调用了delegate的parseBeanDefinitionElement方法区解析出包含了BeanDefinition实例的BeanDefinitionHolder包装实例 
之后就来到了 SpringIOC源码解析（5）—— BeanDefinition的注册中的BeanDefinition的注册环节了，最终将BeanDefinition实例注册到容器里，同时，如果BeanDefinition先前已经注册过了，就需要清空先前的注册信息，如果是单例，将先前已经创建出来的bean实例给清除掉，因为bean实例赖以生存的BeanDefinition已经改变了。