IOC容器的整体功能
从这个图仔细体会Spring框架加载Bean的过程. 有一个全局观.
1:加载Bean的配置（比如xml配置 注解配置)不同类型资源的加载，解析成生成统一Bean的定义.
2:根据Bean的定义加载生成Bean的实例，并放置在Bean容器中
3:对容器中的Bean提供统一的管理和调用
BeanFactory和BeanRegistry：IOC容器功能规范和Bean的注册
BeanFactory：
工厂模式定义了IOC容器的基本功能规范.
/* 例如，如果命名的bean是FactoryBean，则获取将返回Factory，而不是Factory返回的实例。
*/
String FACTORY_BEAN_PREFIX = "&";
/* @throws BeansException if the bean could not be obtained
* 根据bean的名字和Class类型等来得到bean实例
*/
Object getBean(String name) throws BeansException;
/*
* 根据bean的名字和类型获取指定的bean.
*/
<T> T getBean(String name, Class<T> requiredType) throws BeansException;
/* @since 2.5
*/
Object getBean(String name, Object... args) throws BeansException;
/* @see ListableBeanFactory
*/
<T> T getBean(Class<T> requiredType) throws BeansException;
<T> T getBean(Class<T> requiredType, Object... args) throws BeansException;
<T> ObjectProvider<T> getBeanProvider(Class<T> requiredType);
/*
* 返回指定bean的provider.
*/
<T> ObjectProvider<T> getBeanProvider(ResolvableType requiredType);
/*
* 检查工厂中是否包含给定name的bean,或者外部注册的bean.
*/
boolean containsBean(String name);
/*
* 判断所给的name的bean是否为单例.
*/
boolean isSingleton(String name) throws NoSuchBeanDefinitionException;
/*
* 检查所给的name的bean是否为原型bean.
*/
boolean isPrototype(String name) throws NoSuchBeanDefinitionException;
/* @see #getType
*/
boolean isTypeMatch(String name, ResolvableType typeToMatch) throws NoSuchBeanDefinitionException;
/*
* 判断所给name的类型与type是否匹配.
*/
boolean isTypeMatch(String name, Class<?> typeToMatch) throws NoSuchBeanDefinitionException;
/*
* 获取给定name的bean的类型.
*/
@Nullable
Class<?> getType(String name) throws NoSuchBeanDefinitionException;
@Nullable
Class<?> getType(String name, boolean allowFactoryBeanInit) throws NoSuchBeanDefinitionException;
/*
* 返回给定name的bean的名字.
*/
String[] getAliases(String name);
}BeanRegistry：
向IOC容器手工注册 BeanDefinition 对象的方法.
这是这两个接口的关系.很明了.
BeanFactory为何要定义这么多层次的接口.定义了哪些接口.
主要是为了区分在 Spring 内部在操作过程中对象的传递和转化过程中，对对象的数据访问所做的限制。
ListableBeanFactory：
该接口定义了访问容器中 Bean 基本信息的若干方法，如查看Bean 的个数、获取某一类型 Bean 的配置名、查看容器中是否包括某一 Bean 等方法.
HierarchicalBeanFactory：
父子级联 IoC 容器的接口，子容器可以通过接口方法访问父容器； 通过 HierarchicalBeanFactory 接口， Spring 的 IoC 容器可以建立父子层级关联的容器体系，子容器可以访问父容器中的 Bean，但父容器不能访问子容器的 Bean。Spring 使用父子容器实现了很多功能，比如在 Spring MVC 中，展现层 Bean 位于一个子容器中，而业务层和持久层的 Bean 位于父容器中。这样，展现层 Bean 就可以引用业务层和持久层的 Bean，而业务层和持久层的 Bean 则看不到展现层的 Bean.
ConfigurableBeanFactory：
是一个重要的接口，增强了 IoC 容器的可定制性，它定义了设置类装载器、属性编辑器、容器初始化后置处理器等方法.
ConfigurableListableBeanFactory:
ListableBeanFactory 和 ConfigurableBeanFactory的融合.
AutowireCapableBeanFactory：
定义了将容器中的 Bean 按某种规则（如按名字匹配、按类型匹配等）进行自动装配的方法.
如何将Bean注册到BeanFactory中？BeanRegistry
Spring 配置文件中每一个<bean>节点元素在 Spring 容器里都通过一个 BeanDefinition 对象表示，它描述了 Bean 的配置信息。而 BeanDefinitionRegistry 接口提供了向容器手工注册 BeanDefinition 对象的方法。
BeanDefinition：各种Bean对象及其相互的关系
1.BeanDefinition : 定义了各种Bean对象及其相互的关系.
2.BeanDefinitionReader: 这是BeanDefinition的解析器.
3.BeanDefinitionHolder :这是BeanDefination的包装类，用来存储BeanDefinition，name以及aliases等.
从这些类图就足以看出他们之间的关系.
ApplicationContext：IOC接口设计和实现
IoC容器的接口类是ApplicationContext，很显然它必然继承BeanFactory对Bean规范（最基本的ioc容器的实现）进行定义。而ApplicationContext表示的是应用的上下文，除了对Bean的管理外，还至少应该包含了
1:访问资源： 对不同方式的Bean配置（即资源）进行加载。(实现ResourcePatternResolver接口)
2:国际化: 支持信息源，可以实现国际化。（实现MessageSource接口）
3:应用事件: 支持应用事件。(实现ApplicationEventPublisher接口)
ApplicationContext接口的设计
1:HierarchicalBeanFactory 和 ListableBeanFactory： ApplicationContext 继承了 HierarchicalBeanFactory 和 ListableBeanFactory 接口，在此基础上，还通过多个其他的接口扩展了 BeanFactory 的功能：
2:ApplicationEventPublisher：让容器拥有发布应用上下文事件的功能，包括容器启动事件、关闭事件等。实现了 ApplicationListener 事件监听接口的 Bean 可以接收到容器事件 ， 并对事件进行响应处理 。 在 ApplicationContext 抽象实现类AbstractApplicationContext 中，我们可以发现存在一个 ApplicationEventMulticaster，它负责保存所有监听器，以便在容器产生上下文事件时通知这些事件监听者。
3:MessageSource：为应用提供 i18n 国际化消息访问的功能；
4:ResourcePatternResolver ： 所 有 ApplicationContext 实现类都实现了类似于PathMatchingResourcePatternResolver 的功能，可以通过带前缀的 Ant 风格的资源文件路径装载 Spring 的配置文件。
5:LifeCycle：该接口是 Spring 2.0 加入的，该接口提供了 start()和 stop()两个方法，主要用于控制异步处理过程。在具体使用时，该接口同时被 ApplicationContext 实现及具体 Bean 实现， ApplicationContext 会将 start/stop 的信息传递给容器中所有实现了该接口的 Bean，以达到管理和控制 JMX、任务调度等目的。
ApplicationContext接口的实现
第一，从类结构设计上看， 围绕着是否需要Refresh容器衍生出两个抽象类：
1:GenericApplicationContext： 是初始化的时候就创建容器，往后的每次refresh都不会更改
2:AbstractRefreshableApplicationContext： AbstractRefreshableApplicationContext及子类的每次refresh都是先清除已有(如果不存在就创建)的容器，然后再重新创建；AbstractRefreshableApplicationContext及子类无法做到GenericApplicationContext混合搭配从不同源头获取bean的定义信息
第二， 从加载的源来看（比如xml,groovy,annotation等）， 衍生出众多类型的ApplicationContext, 典型比如:
1:FileSystemXmlApplicationContext： 从文件系统下的一个或多个xml配置文件中加载上下文定义，也就是说系统盘符中加载xml配置文件。
2:ClassPathXmlApplicationContext： 从类路径下的一个或多个xml配置文件中加载上下文定义，适用于xml配置的方式。
3:AnnotationConfigApplicationContext： 从一个或多个基于java的配置类中加载上下文定义，适用于java注解的方式。
4:ConfigurableApplicationContext： 扩展于 ApplicationContext，它新增加了两个主要的方法： refresh()和 close()，让 ApplicationContext 具有启动、刷新和关闭应用上下文的能力。在应用上下文关闭的情况下调用 refresh()即可启动应用上下文，在已经启动的状态下，调用 refresh()则清除缓存并重新装载配置信息，而调用close()则可关闭应用上下文。这些接口方法为容器的控制管理带来了便利，但作为开发者，我们并不需要过多关心这些方法。
