spring IOC源码分析（1）

1.何谓Spring IOC

        何谓Spring IOC？书上谓之“依赖注入”，那何谓“依赖注入”？

        作为一个Java程序猿，应该遇到过这样的问题，当你在代码中需要使用某个类提供的功能时，你首先需要new一个对象，给它传递必要的参数，然后才能使用它提供的功能，最后释放对象占用的内存，当然了这个在Java不需要你自己去干了。这也就是说你需要自己去管理变量的整个生命周期，这在大型项目中是很糟糕的。现在好了，有了Spring IOC，这些事情都不需要你去做，你只需要告诉Spring你需要的变量实例，配置其对应关系，Spring就可以讲你依赖的实例注入到你的变量中。

        举个现实的例子，在以前大家找对象都是自己去找，自己去处的，现在不一样了，很多人都通过相亲了，这就有了相亲机构，其实这里相亲机构就是一个Spring IOC容器，你想要找对象，然后你就去找相亲机构，在它那里注个册，告诉它你的要求，比如说高矮胖瘦等等，这个时候，相亲机构就从已经在它那注册了的所有女生中（注：这个时候，你跟那些女生都是相亲机构管理的bean对象）找到符合你要求的女生，最后给到你，让你们自己去折腾了……，这也就是所谓的“依赖注入”，也就是Spring IOC的精髓所在。

 

2 Spring IOC体系结构

 

Bean工厂

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

 

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

 

Bean的表示

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

 

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



        

        

       2. 最基本的IOC容器接口：

       

[java] view plaincopy
 
  1. 1.  public interface BeanFactory {    
  2. 2.      
  3. 3.  //这里是对FactoryBean的转义定义，因为如果使用bean的名字检索FactoryBean得到的对象是工厂生成的对象，    
  4. 4.  //如果需要得到工厂本身，需要转义           
  5. 5.      String FACTORY_BEAN_PREFIX = "&";    
  6. 6.      
  7. 7.      
  8. 8.  //这里根据bean的名字，在IOC容器中得到bean实例，这个IOC容器就是一个大的抽象工厂。    
  9. 9.      Object getBean(String name) throws BeansException;    
  10. 10.     
  11. 11. //这里根据bean的名字和Class类型来得到bean实例，和上面的方法不同在于它会抛出异常：如果根据名字取得的bean实例的Class类型和需要的不同的话。    
  12. 12.     Object getBean(String name, Class requiredType) throws BeansException;    
  13. 13.     
  14. 14. //这里提供对bean的检索，看看是否在IOC容器有这个名字的bean    
  15. 15.     boolean containsBean(String name);    
  16. 16.     
  17. 17.     //这里根据bean名字得到bean实例，并同时判断这个bean是不是单件    
  18. 18.     boolean isSingleton(String name) throws NoSuchBeanDefinitionException;    
  19. 19.     
  20. 20.     //这里对得到bean实例的Class类型    
  21. 21.     Class getType(String name) throws NoSuchBeanDefinitionException;    
  22. 22.     
  23. 23.     //这里得到bean的别名，如果根据别名检索，那么其原名也会被检索出来    
  24. 24.     String[] getAliases(String name);    
  25. 25.     
  26. 26. }   

 

 

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

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

 

 

3.    IoC容器的初始化

 

       

        IoC容器的初始化包括BeanDefinition的Resource定位、载入和注册这三个基本的过程。我们以ApplicationContext为例讲解，ApplicationContext系列容器也许是我们最熟悉的，因为web项目中使用的XmlWebApplicationContext就属于这个继承体系，还有ClasspathXmlApplicationContext等，其继承体系如下图所示：

 

         ApplicationContext允许上下文嵌套，通过保持父上下文可以维持一个上下文体系。对于bean的查找可以在这个上下文体系中发生，首先检查当前上下文，其次是父上下文，逐级向上，这样为不同的Spring应用提供了一个共享的bean定义环境。

 

         从ApplicationContext接口的实现，我们看出其特点：

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

         2.  访问资源。(实现ResourcePatternResolver接口，这个后面要讲)

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

 

         我们看ClassPathXmlApplicationContext是如何建立IOC容器，先看其构造函数：

[java] view plaincopy
 
  1. public ClassPathXmlApplicationContext(String[] configLocations, boolean refresh, ApplicationContext parent)  
  2.             throws BeansException {  
  3.   
  4.         super(parent);  
  5.         setConfigLocations(configLocations);  
  6.         if (refresh) {  
  7.             refresh();  
  8.         }  
  9.     }  

 

         refresh的模板是在AbstractApplicationContext中：

 

[java] view plaincopy
 
  1. public void refresh() throws BeansException, IllegalStateException {  
  2.         synchronized (this.startupShutdownMonitor) {  
  3.             // Prepare this context for refreshing.  
  4.             prepareRefresh();  
  5.   
  6.             // Tell the subclass to refresh the internal bean factory.  
  7.             ConfigurableListableBeanFactory beanFactory = obtainFreshBeanFactory();  
  8.   
  9.             // Prepare the bean factory for use in this context.  
  10.             prepareBeanFactory(beanFactory);  
  11.   
  12.             try {  
  13.                 // Allows post-processing of the bean factory in context subclasses.  
  14.                 postProcessBeanFactory(beanFactory);  
  15.                 // Invoke factory processors registered as beans in the context.  
  16.                 invokeBeanFactoryPostProcessors(beanFactory);  
  17.   
  18.                 // Register bean processors that intercept bean creation.  
  19.                 registerBeanPostProcessors(beanFactory);  
  20.   
  21.                 // Initialize message source for this context.  
  22.                 initMessageSource();  
  23.   
  24.                 // Initialize event multicaster for this context.  
  25.                 initApplicationEventMulticaster();  
  26.   
  27.                 // Initialize other special beans in specific context subclasses.  
  28.                 onRefresh();  
  29.   
  30.                 // Check for listener beans and register them.  
  31.                 registerListeners();  
  32.   
  33.                 // Instantiate all remaining (non-lazy-init) singletons.  
  34.                 finishBeanFactoryInitialization(beanFactory);  
  35.   
  36.                 // Last step: publish corresponding event.  
  37.                 finishRefresh();  
  38.             }  
  39.             ……  

这里是我们分析的入口，其完成了整个的bean初始化过程。

posted @ 2015-10-17 21:39  ljdgm  阅读(376)  评论(0)  编辑  收藏  举报