SpringIOC的设计与实现

Spring的两大核心功能是IOC和AOP，IOC容器为开发者管理对象之间的依赖关系提供了很多便利和基础服务，体现在使用上即在开发时通过注解或xml注入对象，而不是主动new对象。IOC是Inversion of Control的缩写，翻译为控制反转。是面向对象编程中的一种设计原则，可以用来减低计算机代码之间的耦合度。其中最常见的方式叫做依赖注入（Dependency Injection，简称DI），还有一种方式叫”依赖查找”（Dependency Lookup）。通过控制反转，对象在被创建的时候，由一个调控系统内所有对象的外界实体，将其所依赖的对象的引用传递(注入)给它。大型应用中，需要多个类组合工作来实现业务逻辑。这使得每个对象都需要在工作的时候获取到与其合作的对象的引用。如果通过new对象的方式创建实例，代码会变得高度耦合并且难以测试，这对复杂的OOP系统的设计是非常不利的。

IOC的设计理念

IOC的优点是解耦，但我以前对Spring的理解大多停留在使用的层次，对这一点并没有切实的体会，一直不明白IOC的解耦到底解了什么耦。相信对于初学者来说都有同样的疑问，本文主要讲述IOC的设计理念和SpringIOC的实现原理，最后实现一个自定义的IOC框架。实际上IOC并不是Spring的独有，比如Autofac和Ninject 是.NET平台最为流行的IOC框架，Unity是基于C#的IOC框架。为什么我们需要使用IOC，如果不使用IOC会带来什么问题，来看一个例子，对比一下普通写法和注入写法的区别：

// 普通写法
class B{
    // 主动new对象
    A a=new Aimpl();

}

// 注入写法
class B{
    private A a;
    // set方式注入
    public void setA(A a) {
        this.a = a;
    }
}

如果仅仅只看这两段代码的话根本看不出来谁优谁劣，如果要理解控制反转( Inversion of Control )，就有必要先了解软件设计的一个重要思想：依赖倒置原则（Dependency Inversion Principle ）。

依赖倒置原则

什么是依赖倒置原则？假设需要设计一台汽车，这里主要列出汽车的几个重要部件，轮子，底盘，车身，汽车。通常我们的做法是先设计轮子，然后根据轮子大小设计底盘，接着根据底盘设计车身，最后根据车身设计好整个汽车。这里就出现了一个“依赖”关系：汽车依赖车身，车身依赖底盘，底盘依赖轮子。

这样的设计看起来没问题，但是可维护性却很低。假设设计完工之后，上司却突然说根据市场需求的变动，要我们把车子的轮子设计都改大一码。这下我们就蛋疼了：因为我们是根据轮子的尺寸设计的底盘，轮子的尺寸一改，底盘的设计就得修改；同样因为我们是根据底盘设计的车身，那么车身也得改，同理汽车设计也得改——整个设计几乎都得改！

我们现在换一种思路。我们先设计汽车的大概样子，然后根据汽车的样子来设计车身，根据车身来设计底盘，最后根据底盘来设计轮子。这时候，依赖关系就倒置过来了：轮子依赖底盘， 底盘依赖车身， 车身依赖汽车。

这时候，上司再说要改动轮子的设计，我们就只需要改动轮子的设计，而不需要动底盘，车身，汽车的设计了。这就是依赖倒置原则——把原本的高层建筑依赖底层建筑“倒置”过来，变成底层建筑依赖高层建筑。高层建筑决定需要什么，底层去实现这样的需求，但是高层并不用管底层是怎么实现的。这样就不会出现前面的“牵一发动全身”的情况。

控制反转

控制反转（Inversion of Control） 就是依赖倒置原则的一种代码设计的思路。具体采用的方法就是所谓的依赖注入（Dependency Injection）。其实这些概念初次接触都会感到云里雾里的。说穿了，这几种概念的关系大概如下：

为了理解这几个概念，我们还是用上面汽车的例子。换成代码去理解它们，以Java代码为例。

不使用控制反转

我们先不使用控制反转的方式去构建我的汽车，后面我会再使用控制反转的方式，两个对比一下便于理解控制反转的优点，首先先定义四个Class，汽车，车身，底盘，轮胎。然后初始化这辆车，最后跑这辆车。代码结构如下：

这样，上层建筑依赖下层建筑。每一个类的构造函数都直接调用了底层代码的构造函数。假设我们需要改动一下轮胎（Tire）类，把它的尺寸变成动态的，而不是一直都是30。我们需要这样改：

由此我们可以看到，仅仅是为了修改轮胎的构造函数，这种设计却需要修改整个上层所有类的构造函数！在软件工程中，这样的设计几乎是不可维护的——在实际商业的工程项目中，有的类可能会是几千个类的底层，如果每次修改这个类，我们都要修改所有以它作为依赖的类，那软件的维护成本就太高了。面对需求随时可以能变更的市场，这样的代码简直是场灾难。

使用控制反转

所以我们需要进行控制反转（IoC），及上层控制下层，而不是下层控制着上层。我们用依赖注入（Dependency Injection）这种方式来实现控制反转。所谓依赖注入，就是把底层类作为参数传入上层类，实现上层类对下层类的“控制”。这里我们用构造方法传递的依赖注入方式重新写汽车类的定义：

通过注入的方式实现后，我只需要修改轮胎类就行了，不用修改其他任何上层类。这显然是更容易维护的代码。不仅如此，在实际的工程中，这种设计模式还有利于不同组的协同合作和单元测试：比如开发这四个类的分别是四个不同的组，那么只要定义好了接口，四个不同的组可以同时进行开发而不相互受限制；而对于单元测试，如果我们要写Car类的单元测试，就只需要Mock一下Framework类传入Car就行了，而不用把Framework, Bottom, Tire全部new一遍再来构造Car。

这里我们是采用的构造函数传入的方式进行的依赖注入。其实还有另外两种方法：Setter传递和接口传递。这里就不多讲了，核心思路都是一样的，都是为了实现控制反转。

控制反转容器

看到这里你应该能理解什么控制反转和依赖注入了。那什么是控制反转容器(IOC Container)呢？其实上面的例子中，对车类进行初始化的那段代码发生的地方，就是控制反转容器。

显然你也应该观察到了，因为采用了依赖注入，我们使用控制反转的方式实现了一套易于维护的代码，但是在初始化汽车的时候却更加复杂了，我们在创建一辆汽车时，需要初始化每个汽车零部件，而且还需要知道每个零部件的依赖关系，才能组装好一辆汽车，使它运行起来。这样的代码显然也不好维护，IOC容器就解决了这个问题。这个容器可以自动对你的代码进行初始化，你只需要维护一个Configuration（可以是xml可以是一段代码），而不用每次初始化一辆车都要亲手去写那一大段初始化的代码。这是引入IoC Container的第一个好处。IOC Container的第二个好处是：我们在创建实例的时候不需要了解其中的细节。在上面的例子中，我们自己手动创建一个汽车实例时，是从底层往上层new的，我们得知道汽车每个零部件的依赖关系，需要了解整个Car/Framework/Bottom/Tire类构造函数是怎么定义的，才能一步一步new/注入，才能顺序写代码new每个零部件。而IOC Container可以直接隐藏具体的创建实例的细节，在我们来看它就像一个工厂，我们需要什么实例，直接找容器要就行了，它会帮我们分析依赖，并提供一个可用的实例。

实际项目中，有的Service Class可能是十年前写的，有几百个类作为它的底层。假设我们新写的一个API需要实例化这个Service，我们总不可能回头去搞清楚这几百个类的构造函数吧？IoC Container的这个特性就很完美的解决了这类问题——因为这个架构要求你在写class的时候需要写相应的Config文件，所以你要初始化很久以前的Service类的时候，前人都已经写好了Config文件，你直接在需要用的地方注入这个Service就可以了。这大大增加了项目的可维护性且降低了开发难度。

SpringIOC的实现原理

Spring IoC容器的设计主要是基于BeanFactory和ApplicationContext两个接口，其中ApplicationContext是BeanFactory的子接口之一。也就是说BeanFactory是Spring IoC容器所定义的最底层接口，而ApplicationContext是其高级接口之一，并且对BeanFactory功能做了许多有用的扩展，所以在绝大部分的工作场景下，都会使用ApplicationContext作为Spring IoC容器。类图如下

BeanFactory

其中BeanFactory作为最顶层的一个接口类，它定义了IOC容器的基本功能规范，BeanFactory 简单粗暴，可以理解为就是个 HashMap，Key 是 BeanName，Value 是 Bean 实例。通常只提供注册（put），获取（get）这两个功能。我们可以称之为 “低级容器”。BeanFactory 有三个子类：ListableBeanFactory、HierarchicalBeanFactory 和AutowireCapableBeanFactory。在Spring中，实际上是把DefaultListableBeanFactory作为一个默认的功能完整的IoC容器来使用的，从图中可以看出DefaultListableBeanFactory实现了所有的接口。包含了基本IoC容器所具有的重要功能。

public interface BeanFactory {    

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

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

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

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

     //根据bean名字得到bean实例，并同时判断这个bean是不是单例    
     boolean isSingleton(String name) throws NoSuchBeanDefinitionException;    

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

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

 }

ApplicationContext

ApplicationContext 可以称之为 “高级容器”。因为他比 BeanFactory 多了更多的功能。他继承了多个接口。因此具备了更多的功能。例如资源的获取，支持多种消息（例如 JSP tag 的支持），对 BeanFactory 多了工具级别的支持等待。所以你看他的名字，已经不是 BeanFactory 之类的工厂了，而是 “应用上下文”， 代表着整个大容器的所有功能。该接口定义了一个 refresh 方法，此方法是所有阅读 Spring 源码的人的最熟悉的方法，用于刷新整个容器，即重新加载/刷新所有的 bean。ApplicationContext在BeanFactory的基础上集成了MessageSource, ApplicationEventPublisher, ResourcePatternResolver这几个接口，这些接口为ApplicationContext提供了以下BeanFactory不具备的新特性：

• 支持不同的信息源：我们看到ApplicationContext扩展了MessageSource接口，这些信息源的扩展功能可以支持国际化的实现，为开发多语言版本的应用提供服务。
• 访问资源：这一特性体现在对ResourceLoader和Resource的支持上，这样我们可以从不同地方得到Bean定义资源。这种抽象使用户程序可以灵活地定义Bean定义信息，尤其是从不同的I/O途径得到Bean定义信息。
• 支持应用事件：继承了接口ApplicationEventPublisher，从而在上下文中引入了事件机制。这些事件和Bean的生命周期的结合为Bean的管理提供了便利。
• 在ApplicationContext中提供的附加服务：这些服务使得基本IoC容器的功能更丰富。因为具备了这些丰富的附加功能，使得ApplicationContext与简单的BeanFactory相比，对它的使用是一种面向框架的使用风格，所以一般建议在开发应用时使用ApplicationContext作为IoC容器的基本形式。

Spring IoC容器对Bean定义资源的载入是从refresh()函数开始的，refresh()是一个模板方法，refresh()方法的作用是：在创建IoC容器前，如果已经有容器存在，则需要把已有的容器销毁和关闭，以保证在refresh之后使用的是新建立起来的IoC容器。refresh的作用类似于对IoC容器的重启，在新建立好的容器中对容器进行初始化，对Bean定义资源进行载入

public void refresh() throws BeansException, IllegalStateException {  
       synchronized (this.startupShutdownMonitor) {  
           //调用容器准备刷新的方法，获取容器的当时时间，同时给容器设置同步标识  
           prepareRefresh();  
           //告诉子类启动refreshBeanFactory()方法，Bean定义资源文件的载入从  
          //子类的refreshBeanFactory()方法启动  
           ConfigurableListableBeanFactory beanFactory = obtainFreshBeanFactory();  
           //为BeanFactory配置容器特性，例如类加载器、事件处理器等  
           prepareBeanFactory(beanFactory);  
            try {  
                //为容器的某些子类指定特殊的BeanPost事件处理器  
                postProcessBeanFactory(beanFactory);  
                //调用所有注册的BeanFactoryPostProcessor的Bean  
                invokeBeanFactoryPostProcessors(beanFactory);  
                //为BeanFactory注册BeanPost事件处理器.  
                //BeanPostProcessor是Bean后置处理器，用于监听容器触发的事件  
                registerBeanPostProcessors(beanFactory);  
                //初始化信息源，和国际化相关.  
                initMessageSource();  
                //初始化容器事件传播器.  
                initApplicationEventMulticaster();  
                //调用子类的某些特殊Bean初始化方法  
                onRefresh();  
                //为事件传播器注册事件监听器.  
                registerListeners();  
                //初始化所有剩余的单态Bean.  
                finishBeanFactoryInitialization(beanFactory);  
                //初始化容器的生命周期事件处理器，并发布容器的生命周期事件  
                finishRefresh();  
            }  
            catch (BeansException ex) {  
                //销毁以创建的单态Bean  
                destroyBeans();  
                //取消refresh操作，重置容器的同步标识.  
                cancelRefresh(ex);  
                throw ex;  
            }  
        }  
    }

Spring Bean的作用域

在Spring中自定义的实例，在IOC容器中默认是单例的，当你定义一个bean定义且设置它的作用域为singleton，Spring IOC只会给这个bean定义创建一个实例．这些单例bean的单个实例被存储在容器中，后续所有请求和引用这个bean都返回容器中的对象，Spring实例还有一些其他的作用域

作用域	描述
单例 （singleton）	(默认)bean实例的作用范围是spring IoC容器创建后到spring IoC销毁．每次请求bean实例都是获取到同一个bean
原型 （prototype）	每次请求bean的时候都返回一个新的bean实例．它的作用域是它所在的对象
请求 (request)	bean实例的作用范围这个请求的生命周期，请求完成后这个bean就被销毁．因此每个请求都会创建自己的bean实例．只在web应用中有效
会话 (session)	bean实例的作用范围是这个http session的生命周期．只在web应用中有效
应用程序 (application)	bean实例的作用范围是ServletContext的生命周期．只在web应用中有效
websocket (websocket)	bean实例的作用范围是webscoket的生命周期