Spring5源码分析（一） IOC和Spring 核心容器体系结构

1.什么是 IOC/DI？

  IOC(Inversion of Control)控制反转：所谓控制反转，就是把原先咱们代码里面须要实现的对象建立、依赖的代码，反转给容器来帮忙实现。那么必然的咱们须要建立一个容器，同时须要一种描述来让容器知道须要建立的对象与对象的关系。这个描述最具体表现就是咱们可配置的文件。
  DI(Dependency Injection)依赖注入：就是指对象是被动接受依赖类而不是本身主动去找，换句话说
就是指对象不是从容器中查找它依赖的类，而是在容器实例化对象的时候主动将它依赖的类注入给它。

咱们本身如何设计一个IOC容器，会有哪些须要思考呢？
1. 对象和对象关系怎么表示？
能够用 xml，properties 文件等语义化配置文件表示。
2. 描述对象关系的文件存放在哪里？
多是 classpath，filesystem，或者是 URL 网络资源，servletContext 等。

有了配置文件，还须要对配置文件解析。
不一样的配置文件对对象的描述不同，如标准的，自定义声明式的，如何统一？在内部须要有一个统一
的关于对象的定义，全部外部的描述都必须转化成统一的描述定义。
如何对不一样的配置文件进行解析？须要对不一样的配置文件语法，采用不一样的解析器。

2.Spring 核心容器体系结构

(1) BeanFactory

  Spring Bean 的建立是典型的工厂模式，这一系列的 Bean 工厂，也即 IOC 容器为开发者管理对象间的依赖关系提供了不少便利和基础服务，在 Spring 中有许多的 IOC 容器的实现供用户选择和使用，
其相互关系以下：

其中 BeanFactory 做为最顶层的一个接口类，它定义了IOC容器的基本功能规范，BeanFactory有三个直接的子类：ListableBeanFactory、HierarchicalBeanFactory 和 AutowireCapableBeanFactory。
可是从上图中咱们能够发现最终的默认实现类是DefaultListableBeanFactory，他实现了全部的接口。那为什么要定义这么多层次的接口呢？查阅这些接口的源码和说明发现，每一个接口都有他使用的场合，它主要是为了区分在 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> T getBean(String name, @Nullable Class<T> requiredType) throws BeansException;
//根据名字和参数 在IOC容器中获取bean的实例
Object getBean(String name, Object... args) throws BeansException;
<T> T getBean(Class<T> requiredType) throws BeansException;
//根据类型和参数 在IOC容器中获取bean的实例
<T> T getBean(Class<T> 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 容器的实现。好比XmlBeanFactory，ClasspathXmlApplicationContext 等。其中XmlBeanFactory就是针对最基本的IOC容器的实现，这个 IOC 容器能够读取 XML 文件定义的 BeanDefinition（XML 文件
中对 bean 的描述）,若是说XmlBeanFactory是容器中的屌丝，ApplicationContext 应该算容器中的高帅富.不过在Spring5.0中XmlBeanFactory已经标志为废弃。
  ApplicationContext是Spring提供的一个高级的IOC容器，它除了可以提供 IOC 容器的基本功能外，还为用户提供了如下的附加服务。

从 ApplicationContext 接口的实现，咱们看出其特色：
1.支持信息源，能够实现国际化。（实现 MessageSource 接口）
2.访问资源。(实现 ResourcePatternResolver 接口)
3.支持应用事件。(实现 ApplicationEventPublisher 接口)

(2) BeanDefinition

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

Bean 的解析过程很是复杂，功能被分的很细，由于这里须要被扩展的地方不少，必须保证有足够的灵活性，以应对可能的变化。Bean的解析主要就是对 Spring 配置文件的解析。这个解析过程主要经过下图中的类完成：

文档有参考其余资料，若是问题请联系我，进行删除！