Spring IOC容器的初体验

2021-05-02 01:29

阅读：397

其中 BeanFactory 作为最顶层的一个接口类，它定义了 IOC 容器的基本功能规范，BeanFactory 有三个重要的子类：ListableBeanFactory、HierarchicalBeanFactory 和 AutowireCapableBeanFactory。但是从类图中我们可以发现最终的默认实现类是DefaultListable-BeanFactory，它实现了所有的接口。那为何要定义这么多层次的接口呢？查阅这些接口的源码和说明发现，每个接口都有它使用的场合，它主要是为了区分在 Spring 内部在操作过程中对象的传递和转化过程时，对对象的数据访问所做的限制。例如 ListableBeanFactory 接口表示这些 Bean 是可列表化的，而 HierarchicalBeanFactory 表示的是这些 Bean 是有继承关系的，也就是每个 Bean 有可能有父 Bean。AutowireCapableBeanFactory 接口定义 Bean 的自动装配规则。这三个接口共同定义了 Bean 的集合、Bean 之间的关系、以及 Bean 行为。最基本的 IOC 容器接口 BeanFactory，来看一下它的源码：

public interface BeanFactory {
        // 对 FactoryBean 的转义定义，因为如果使用 bean 的名字检索 FactoryBean 得到的对象是工厂生成的对象，如果需要得到工厂本身，需要转义
        String FACTORY_BEAN_PREFIX = "&";

        // 根据 bean 的名字，获取在 IOC 容器中得到 bean 实例
        Object getBean(String name) throws BeansException;

        // 根据 bean 的名字和 Class 类型来得到 bean 实例，增加了类型安全验证机制。
         T getBean(String name, @Nullable Class requiredType) throws BeansException;
        Object getBean(String name, Object... args) throws BeansException;
         T getBean(Class requiredType) throws BeansException;  T getBean(Class requiredType, Object... args) throws BeansException;

        // 提供对 bean 的检索，看看是否在 IOC 容器有这个名字的
        bean boolean containsBean(String name);

        // 根据 bean 名字得到 bean 实例，并同时判断这个 bean 是不是单例
        boolean isSingleton(String name) throws NoSuchBeanDefinitionException;
        boolean isPrototype(String name) throws NoSuchBeanDefinitionException;
        boolean isTypeMatch(String name, ResolvableType typeToMatch) throws NoSuchBeanDefinitionException;
        boolean isTypeMatch(String name, @Nullable Class> typeToMatch) throws NoSuchBeanDefinitionException;

        // 得到 bean 实例的 Class 类型
        @Nullable
        Class> getType(String name) throws NoSuchBeanDefinitionException;

        // 得到 bean 的别名，如果根据别名检索，那么其原名也会被检索出来
        String[] getAliases(String name);
    }

在 BeanFactory 里只对 IOC 容器的基本行为作了定义，根本不关心你的 Bean 是如何定义怎样加载的。正如我们只关心工厂里得到什么的产品对象，至于工厂是怎么生产这些对象的，这个基本的接口不关心。

而要知道工厂是如何产生对象的，我们需要看具体的 IOC 容器实现，Spring 提供了许多 IOC 容器的实现。比如 GenericApplicationContext ， ClasspathXmlApplicationContext 等。

ApplicationContext 是 Spring 提供的一个高级的 IOC 容器，它除了能够提供 IOC 容器的基本功能外，还为用户提供了以下的附加服务。从 ApplicationContext 接口的实现，我们看出其特点：

　　1、支持信息源，可以实现国际化。（实现 MessageSource 接口）

　　2、访问资源。(实现 ResourcePatternResolver 接口，后面章节会讲到)

　　3、支持应用事件。(实现 ApplicationEventPublisher 接口)

2、BeanDefinition

SpringIOC 容器管理了我们定义的各种 Bean 对象及其相互的关系，Bean 对象在 Spring 实现中是以 BeanDefinition 来描述的，其继承体系如下：

3、BeanDefinitionReader

Bean 的解析过程非常复杂，功能被分的很细，因为这里需要被扩展的地方很多，必须保证有足够的灵活性，以应对可能的变化。Bean 的解析主要就是对 Spring 配置文件的解析。这个解析过程主要通过BeanDefintionReader 来完成，最后看看 Spring 中 BeanDefintionReader 的类结构图：

通过以上分析，我们对 Spring 框架体系有了一个基本的宏观了解，希望朋友们好好理解，最好在脑海中形成画面，为接下来的学习打下良好的铺垫。

Web IOC 容器初体验

我们还是从大家最熟悉的 DispatcherServlet 开始，我们最先想到的还是 DispatcherServlet 的 init()方法。我们发现在 DispatherServlet 中并没有找到 init()方法。但是经过探索，往上追索在其父类HttpServletBean 中找到了我们想要的 init()方法，如下：

在 init()方法中，真正完成初始化容器动作的逻辑其实在 initServletBean()方法中，我们继续跟进initServletBean()中的代码在 FrameworkServlet 类中：

技术图片

在上面的代码中终于看到了我们似曾相识的代码 initWebAppplicationContext()，继续跟进：

技术图片

从上面的代码中可以看出，在 configAndRefreshWebApplicationContext()方法中，调用 refresh()方法，这个是真正启动 IOC 容器的入口，后面会详细介绍。IOC 容器初始化以后，最后调用了Dispatcher—Servlet 的 onRefresh()方法，在 onRefresh()方法中又是直接调用 initStrategies()方法初始化 SpringMVC 的九大组件：

技术图片