Spring源代码解析(一）：IOC容器

在认真学习Rod.Johnson的三部曲之一：<<Professional Java Development with the spring framework>>,顺便也看了看源代码想知道个究竟，抛砖引玉，有兴趣的同志一起讨论研究吧！
以下内容引自博客：http://jiwenke-spring.blogspot.com/,欢迎指导：）
在Spring中，IOC容器的重要地位我们就不多说了，对于Spring的使用者而言，IOC容器实际上是什么呢？我们可以说BeanFactory就是我们看到的IoC容器，当然了Spring为我们准备了许多种IoC容器来使用，这样可以方便我们从不同的层面，不同的资源位置，不同的形式的定义信息来建立我们需要的IoC容器。
在Spring中，最基本的IOC容器接口是BeanFactory - 这个接口为具体的IOC容器的实现作了最基本的功能规定 - 不管怎么着，作为IOC容器，这些接口你必须要满足应用程序的最基本要求：

public interface BeanFactory {

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


    //这里根据bean的名字，在IOC容器中得到bean实例，这个IOC容器就是一个大的抽象工厂。
    Object getBean(String name) throws BeansException;

    //这里根据bean的名字和Class类型来得到bean实例，和上面的方法不同在于它会抛出异常：如果根据名字取得的bean实例的Class类型和需要的不同的话。
    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);

}

在BeanFactory里只对IOC容器的基本行为作了定义，根本不关心你的bean是怎样定义怎样加载的 - 就像我们只关心从这个工厂里我们得到到什么产品对象，至于工厂是怎么生产这些对象的，这个基本的接口不关心这些。如果要关心工厂是怎样产生对象的，应用程序需要使用具体的IOC容器实现- 当然你可以自己根据这个BeanFactory来实现自己的IOC容器，但这个没有必要，因为Spring已经为我们准备好了一系列工厂来让我们使用。比如XmlBeanFactory就是针对最基础的BeanFactory的IOC容器的实现 - 这个实现使用xml来定义IOC容器中的bean。
Spring提供了一个BeanFactory的基本实现，XmlBeanFactory同样的通过使用模板模式来得到对IOC容器的抽象- AbstractBeanFactory,DefaultListableBeanFactory这些抽象类为其提供模板服务。其中通过resource 接口来抽象bean定义数据，对Xml定义文件的解析通过委托给XmlBeanDefinitionReader来完成。下面我们根据书上的例子，简单的演示IOC容器的创建过程：

    ClassPathResource res = new ClassPathResource("beans.xml");
    DefaultListableBeanFactory factory = new DefaultListableBeanFactory();
    XmlBeanDefinitionReader reader = new XmlBeanDefinitionReader(factory);
    reader.loadBeanDefinitions(res);

这些代码演示了以下几个步骤：

   1. 创建IOC配置文件的抽象资源
   2. 创建一个BeanFactory
   3. 把读取配置信息的BeanDefinitionReader,这里是XmlBeanDefinitionReader配置给BeanFactory
   4. 从定义好的资源位置读入配置信息，具体的解析过程由XmlBeanDefinitionReader来完成，这样完成整个载入bean定义的过程。我们的IoC容器就建立起来了。在BeanFactory的源代码中我们可以看到：

public class XmlBeanFactory extends DefaultListableBeanFactory {
    //这里为容器定义了一个默认使用的bean定义读取器
    private final XmlBeanDefinitionReader reader = new XmlBeanDefinitionReader(this);
    public XmlBeanFactory(Resource resource) throws BeansException {
        this(resource, null);
    }
    //在初始化函数中使用读取器来对资源进行读取，得到bean定义信息。
    public XmlBeanFactory(Resource resource, BeanFactory parentBeanFactory) throws BeansException {
        super(parentBeanFactory);
        this.reader.loadBeanDefinitions(resource);
    }

我们在后面会看到读取器读取资源和注册bean定义信息的整个过程，基本上是和上下文的处理是一样的，从这里我们可以看到上下文和 XmlBeanFactory这两种IOC容器的区别，BeanFactory往往不具备对资源定义的能力，而上下文可以自己完成资源定义，从这个角度上看上下文更好用一些。
仔细分析Spring BeanFactory的结构，我们来看看在BeanFactory基础上扩展出的ApplicationContext - 我们最常使用的上下文。除了具备BeanFactory的全部能力，上下文为应用程序又增添了许多便利：

    * 可以支持不同的信息源，我们看到ApplicationContext扩展了MessageSource
    * 访问资源 , 体现在对ResourceLoader和Resource的支持上面，这样我们可以从不同地方得到bean定义资源
    * 支持应用事件，继承了接口ApplicationEventPublisher,这样在上下文中引入了事件机制而BeanFactory是没有的。

ApplicationContext允许上下文嵌套 - 通过保持父上下文可以维持一个上下文体系 - 这个体系我们在以后对Web容器中的上下文环境的分析中可以清楚地看到。对于bean的查找可以在这个上下文体系中发生，首先检查当前上下文，其次是父上下文，逐级向上，这样为不同的Spring应用提供了一个共享的bean定义环境。这个我们在分析Web容器中的上下文环境时也能看到。
ApplicationContext提供IoC容器的主要接口，在其体系中有许多抽象子类比如AbstractApplicationContext为具体的BeanFactory的实现，比如FileSystemXmlApplicationContext和 ClassPathXmlApplicationContext提供上下文的模板，使得他们只需要关心具体的资源定位问题。当应用程序代码实例化 FileSystemXmlApplicationContext的时候，得到IoC容器的一种具体表现 - ApplicationContext，从而应用程序通过ApplicationContext来管理对bean的操作。
BeanFactory 是一个接口，在实际应用中我们一般使用ApplicationContext来使用IOC容器，它们也是IOC容器展现给应用开发者的使用接口。对应用程序开发者来说，可以认为BeanFactory和ApplicationFactory在不同的使用层面上代表了SPRING提供的IOC容器服务。
下面我们具体看看通过FileSystemXmlApplicationContext是怎样建立起IOC容器的, 显而易见我们可以通过new来得到IoC容器：

   ApplicationContext = new FileSystemXmlApplicationContext(xmlPath);

调用的是它初始化代码：

    public FileSystemXmlApplicationContext(String[] configLocations, boolean refresh, ApplicationContext parent)
            throws BeansException {
        super(parent);
        this.configLocations = configLocations;
        if (refresh) {
          　//这里是IoC容器的初始化过程，其初始化过程的大致步骤由AbstractApplicationContext来定义
            refresh();
        }
    }

refresh的模板在AbstractApplicationContext:

    public void refresh() throws BeansException, IllegalStateException {
        synchronized (this.startupShutdownMonitor) {
            synchronized (this.activeMonitor) {
                this.active = true;
            }

            // 这里需要子类来协助完成资源位置定义,bean载入和向IOC容器注册的过程
            refreshBeanFactory();
            ............
     }

这个方法包含了整个BeanFactory初始化的过程，对于特定的FileSystemXmlBeanFactory,我们看到定位资源位置由refreshBeanFactory()来实现：
在AbstractXmlApplicationContext中定义了对资源的读取过程，默认由XmlBeanDefinitionReader来读取：

    protected void loadBeanDefinitions(DefaultListableBeanFactory beanFactory) throws IOException {
        // 这里使用XMLBeanDefinitionReader来载入bean定义信息的XML文件
        XmlBeanDefinitionReader beanDefinitionReader = new XmlBeanDefinitionReader(beanFactory);

        //这里配置reader的环境，其中ResourceLoader是我们用来定位bean定义信息资源位置的
        ///因为上下文本身实现了ResourceLoader接口，所以可以直接把上下文作为ResourceLoader传递给XmlBeanDefinitionReader
        beanDefinitionReader.setResourceLoader(this);
        beanDefinitionReader.setEntityResolver(new ResourceEntityResolver(this));

        initBeanDefinitionReader(beanDefinitionReader);
        //这里转到定义好的XmlBeanDefinitionReader中对载入bean信息进行处理
        loadBeanDefinitions(beanDefinitionReader);
    }

转到beanDefinitionReader中进行处理：

    protected void loadBeanDefinitions(XmlBeanDefinitionReader reader) throws BeansException, IOException {
        Resource[] configResources = getConfigResources();
        if (configResources != null) {
            //调用XmlBeanDefinitionReader来载入bean定义信息。
            reader.loadBeanDefinitions(configResources);
        }
        String[] configLocations = getConfigLocations();
        if (configLocations != null) {
            reader.loadBeanDefinitions(configLocations);
        }
    }

而在作为其抽象父类的AbstractBeanDefinitionReader中来定义载入过程：

    public int loadBeanDefinitions(String location) throws BeanDefinitionStoreException {
     //这里得到当前定义的ResourceLoader,默认的我们使用DefaultResourceLoader
     ResourceLoader resourceLoader = getResourceLoader();
     .........//如果没有找到我们需要的ResourceLoader，直接抛出异常
        if (resourceLoader instanceof ResourcePatternResolver) {
            // 这里处理我们在定义位置时使用的各种pattern,需要ResourcePatternResolver来完成
            try {
                Resource[] resources = ((ResourcePatternResolver) resourceLoader).getResources(location);
                int loadCount = loadBeanDefinitions(resources);
                return loadCount;
            }
          ........
        }
        else {
            // 这里通过ResourceLoader来完成位置定位
            Resource resource = resourceLoader.getResource(location);
            // 这里已经把一个位置定义转化为Resource接口，可以供XmlBeanDefinitionReader来使用了
            int loadCount = loadBeanDefinitions(resource);
            return loadCount;
        }
    }

当我们通过ResourceLoader来载入资源，别忘了了我们的GenericApplicationContext也实现了ResourceLoader接口：

    public class GenericApplicationContext extends AbstractApplicationContext implements BeanDefinitionRegistry {
        public Resource getResource(String location) {
            //这里调用当前的loader也就是DefaultResourceLoader来完成载入
            if (this.resourceLoader != null) {
                return this.resourceLoader.getResource(location);
            }
            return super.getResource(location);
        }
    .......
    }

而我们的FileSystemXmlApplicationContext就是一个DefaultResourceLoader - GenericApplicationContext()通过DefaultResourceLoader:

    public Resource getResource(String location) {
        //如果是类路径的方式，那需要使用ClassPathResource来得到bean文件的资源对象
        if (location.startsWith(CLASSPATH_URL_PREFIX)) {
            return new ClassPathResource(location.substring(CLASSPATH_URL_PREFIX.length()), getClassLoader());
        }
        else {
            try {
                // 如果是URL方式，使用UrlResource作为bean文件的资源对象
                URL url = new URL(location);
                return new UrlResource(url);
            }
            catch (MalformedURLException ex) {
                // 如果都不是，那我们只能委托给子类由子类来决定使用什么样的资源对象了
                return getResourceByPath(location);
            }
        }
    }

我们的FileSystemXmlApplicationContext本身就是是DefaultResourceLoader的实现类，他实现了以下的接口：

    protected Resource getResourceByPath(String path) {
        if (path != null && path.startsWith("/")) {
            path = path.substring(1);
        }
        //这里使用文件系统资源对象来定义bean文件
        return new FileSystemResource(path);
    }

这样代码就回到了FileSystemXmlApplicationContext中来，他提供了FileSystemResource来完成从文件系统得到配置文件的资源定义。这样，就可以从文件系统路径上对IOC配置文件进行加载 - 当然我们可以按照这个逻辑从任何地方加载，在Spring中我们看到它提供的各种资源抽象，比如ClassPathResource, URLResource,FileSystemResource等来供我们使用。上面我们看到的是定位Resource的一个过程，而这只是加载过程的一部分 - 我们回到AbstractBeanDefinitionReaderz中的loadDefinitions(resource)来看看得到代表bean文件的资源定义以后的载入过程,默认的我们使用XmlBeanDefinitionReader：

    public int loadBeanDefinitions(EncodedResource encodedResource) throws BeanDefinitionStoreException {
        .......
        try {
            //这里通过Resource得到InputStream的IO流
            InputStream inputStream = encodedResource.getResource().getInputStream();
            try {
                //从InputStream中得到XML的解析源
                InputSource inputSource = new InputSource(inputStream);
                if (encodedResource.getEncoding() != null) {
                    inputSource.setEncoding(encodedResource.getEncoding());
                }
                //这里是具体的解析和注册过程
                return doLoadBeanDefinitions(inputSource, encodedResource.getResource());
            }
            finally {
                //关闭从Resource中得到的IO流
                inputStream.close();
            }
        }
           .........
    }

    protected int doLoadBeanDefinitions(InputSource inputSource, Resource resource)
            throws BeanDefinitionStoreException {
        try {
            int validationMode = getValidationModeForResource(resource);
            //通过解析得到DOM，然后完成bean在IOC容器中的注册
            Document doc = this.documentLoader.loadDocument(
                    inputSource, this.entityResolver, this.errorHandler, validationMode, this.namespaceAware);
            return registerBeanDefinitions(doc, resource);
        }
    .......
    }

我们看到先把定义文件解析为DOM对象，然后进行具体的注册过程：

    public int registerBeanDefinitions(Document doc, Resource resource) throws BeanDefinitionStoreException {
        // 这里定义解析器，使用XmlBeanDefinitionParser来解析xml方式的bean定义文件 - 现在的版本不用这个解析器了，使用的是XmlBeanDefinitionReader
        if (this.parserClass != null) {
            XmlBeanDefinitionParser parser =
                    (XmlBeanDefinitionParser) BeanUtils.instantiateClass(this.parserClass);
            return parser.registerBeanDefinitions(this, doc, resource);
        }
        // 具体的注册过程,首先得到XmlBeanDefinitionReader,来处理xml的bean定义文件
        BeanDefinitionDocumentReader documentReader = createBeanDefinitionDocumentReader();
        int countBefore = getBeanFactory().getBeanDefinitionCount();
        documentReader.registerBeanDefinitions(doc, createReaderContext(resource));
        return getBeanFactory().getBeanDefinitionCount() - countBefore;
    }

具体的在BeanDefinitionDocumentReader中完成对，下面是一个简要的注册过程来完成bean定义文件的解析和IOC容器中bean的初始化

    public void registerBeanDefinitions(Document doc, XmlReaderContext readerContext) {
        this.readerContext = readerContext;

        logger.debug("Loading bean definitions");
        Element root = doc.getDocumentElement();

        BeanDefinitionParserDelegate delegate = createHelper(readerContext, root);

        preProcessXml(root);
        parseBeanDefinitions(root, delegate);
        postProcessXml(root);
    }

    protected void parseBeanDefinitions(Element root, BeanDefinitionParserDelegate delegate) {
        if (delegate.isDefaultNamespace(root.getNamespaceURI())) {
            //这里得到xml文件的子节点，比如各个bean节点         
            NodeList nl = root.getChildNodes();

            //这里对每个节点进行分析处理
            for (int i = 0; i < nl.getLength(); i++) {
                Node node = nl.item(i);
                if (node instanceof Element) {
                    Element ele = (Element) node;
                    String namespaceUri = ele.getNamespaceURI();
                    if (delegate.isDefaultNamespace(namespaceUri)) {
                        //这里是解析过程的调用，对缺省的元素进行分析比如bean元素
                        parseDefaultElement(ele, delegate);
                    }
                    else {
                        delegate.parseCustomElement(ele);
                    }
                }
            }
        } else {
            delegate.parseCustomElement(root);
        }
    }

    private void parseDefaultElement(Element ele, BeanDefinitionParserDelegate delegate) {
        //这里对元素Import进行处理
        if (DomUtils.nodeNameEquals(ele, IMPORT_ELEMENT)) {
            importBeanDefinitionResource(ele);
        }
        else if (DomUtils.nodeNameEquals(ele, ALIAS_ELEMENT)) {
            String name = ele.getAttribute(NAME_ATTRIBUTE);
            String alias = ele.getAttribute(ALIAS_ATTRIBUTE);
            getReaderContext().getReader().getBeanFactory().registerAlias(name, alias);
            getReaderContext().fireAliasRegistered(name, alias, extractSource(ele));
        }
        //这里对我们最熟悉的bean元素进行处理
        else if (DomUtils.nodeNameEquals(ele, BEAN_ELEMENT)) {
            //委托给BeanDefinitionParserDelegate来完成对bean元素的处理，这个类包含了具体的bean解析的过程。
            // 把解析bean文件得到的信息放到BeanDefinition里，他是bean信息的主要载体，也是IOC容器的管理对象。
            BeanDefinitionHolder bdHolder = delegate.parseBeanDefinitionElement(ele);
            if (bdHolder != null) {
                bdHolder = delegate.decorateBeanDefinitionIfRequired(ele, bdHolder);
                // 这里是向IOC容器注册，实际上是放到IOC容器的一个map里
                BeanDefinitionReaderUtils.registerBeanDefinition(bdHolder, getReaderContext().getRegistry());

                // 这里向IOC容器发送事件，表示解析和注册完成。
                getReaderContext().fireComponentRegistered(new BeanComponentDefinition(bdHolder));
            }
        }
    }

我们看到在parseBeanDefinition中对具体bean元素的解析式交给BeanDefinitionParserDelegate来完成的，下面我们看看解析完的bean是怎样在IOC容器中注册的：
在BeanDefinitionReaderUtils调用的是：

    public static void registerBeanDefinition(
            BeanDefinitionHolder bdHolder, BeanDefinitionRegistry beanFactory) throws BeansException {

        // 这里得到需要注册bean的名字；
        String beanName = bdHolder.getBeanName();
        //这是调用IOC来注册的bean的过程，需要得到BeanDefinition
        beanFactory.registerBeanDefinition(beanName, bdHolder.getBeanDefinition());

        // 别名也是可以通过IOC容器和bean联系起来的进行注册
        String[] aliases = bdHolder.getAliases();
        if (aliases != null) {
            for (int i = 0; i < aliases.length; i++) {
                beanFactory.registerAlias(beanName, aliases[i]);
            }
        }
    }

我们看看XmlBeanFactory中的注册实现：

    //---------------------------------------------------------------------
    // 这里是IOC容器对BeanDefinitionRegistry接口的实现
    //---------------------------------------------------------------------

    public void registerBeanDefinition(String beanName, BeanDefinition beanDefinition)
            throws BeanDefinitionStoreException {

        .....//这里省略了对BeanDefinition的验证过程
        //先看看在容器里是不是已经有了同名的bean,如果有抛出异常。
        Object oldBeanDefinition = this.beanDefinitionMap.get(beanName);
        if (oldBeanDefinition != null) {
            if (!this.allowBeanDefinitionOverriding) {
            ...........
        }
        else {
            //把bean的名字加到IOC容器中去
            this.beanDefinitionNames.add(beanName);
        }
        //这里把bean的名字和Bean定义联系起来放到一个HashMap中去,IOC容器通过这个Map来维护容器里的Bean定义信息。
        this.beanDefinitionMap.put(beanName, beanDefinition);
        removeSingleton(beanName);
    }

这样就完成了Bean定义在IOC容器中的注册，就可被IOC容器进行管理和使用了。
从上面的代码来看，我们总结一下IOC容器初始化的基本步骤：

    * 初始化的入口在容器实现中的refresh()调用来完成
    * 对bean 定义载入IOC容器使用的方法是loadBeanDefinition,其中的大致过程如下：通过ResourceLoader来完成资源文件位置的定位，DefaultResourceLoader是默认的实现，同时上下文本身就给出了ResourceLoader的实现，可以从类路径，文件系统, URL等方式来定为资源位置。如果是XmlBeanFactory作为IOC容器，那么需要为它指定bean定义的资源，也就是说bean定义文件时通过抽象成Resource来被IOC容器处理的，容器通过BeanDefinitionReader来完成定义信息的解析和Bean信息的注册,往往使用的是XmlBeanDefinitionReader来解析bean的xml定义文件 - 实际的处理过程是委托给BeanDefinitionParserDelegate来完成的，从而得到bean的定义信息，这些信息在Spring中使用BeanDefinition对象来表示 - 这个名字可以让我们想到loadBeanDefinition,RegisterBeanDefinition这些相关的方法 - 他们都是为处理BeanDefinitin服务的，IoC容器解析得到BeanDefinition以后，需要把它在IOC容器中注册，这由IOC实现 BeanDefinitionRegistry接口来实现。注册过程就是在IOC容器内部维护的一个HashMap来保存得到的 BeanDefinition的过程。这个HashMap是IoC容器持有bean信息的场所，以后对bean的操作都是围绕这个HashMap来实现的。
    * 然后我们就可以通过BeanFactory和ApplicationContext来享受到Spring IOC的服务了.
在使用IOC容器的时候，我们注意到除了少量粘合代码，绝大多数以正确IoC风格编写的应用程序代码完全不用关心如何到达工厂，因为容器将把这些对象与容器管理的其他对象钩在一起。基本的策略是把工厂放到已知的地方，最好是放在对预期使用的上下文有意义的地方，以及代码将实际需要访问工厂的地方。 Spring本身提供了对声明式载入web应用程序用法的应用程序上下文，并将其存储在ServletContext中的框架实现。具体可以参见以后的文章。
在使用Spring IOC容器的时候我们还需要区别两个概念：
Beanfactory 和Factory bean，其中BeanFactory指的是IOC容器的编程抽象，比如ApplicationContext， XmlBeanFactory等，这些都是IOC容器的具体表现，需要使用什么样的容器由客户决定但Spring为我们提供了丰富的选择。而 FactoryBean只是一个可以在IOC容器中被管理的一个bean,是对各种处理过程和资源使用的抽象,Factory bean在需要时产生另一个对象，而不返回FactoryBean本省，我们可以把它看成是一个抽象工厂，对它的调用返回的是工厂生产的产品。所有的 Factory bean都实现特殊的org.springframework.beans.factory.FactoryBean接口，当使用容器中factory bean的时候，该容器不会返回factory bean本身，而是返回其生成的对象。Spring包括了大部分的通用资源和服务访问抽象的Factory bean的实现，其中包括：
对JNDI查询的处理，对代理对象的处理，对事务性代理的处理，对RMI代理的处理等，这些我们都可以看成是具体的工厂，看成是SPRING为我们建立好的工厂。也就是说Spring通过使用抽象工厂模式为我们准备了一系列工厂来生产一些特定的对象，免除我们手工重复的工作，我们要使用时只需要在IOC容器里配置好就能很方便的使用了。
现在我们来看看在Spring的事件机制，Spring中有3个标准事件，ContextRefreshEvent, ContextCloseEvent,RequestHandledEvent他们通过ApplicationEvent接口，同样的如果需要自定义时间也只需要实现ApplicationEvent接口，参照ContextCloseEvent的实现可以定制自己的事件实现：

public class ContextClosedEvent extends ApplicationEvent {

    public ContextClosedEvent(ApplicationContext source) {
        super(source);
    }

    public ApplicationContext getApplicationContext() {
        return (ApplicationContext) getSource();
    }
}

可以通过显现ApplicationEventPublishAware接口，将事件发布器耦合到ApplicationContext这样可以使用 ApplicationContext框架来传递和消费消息,然后在ApplicationContext中配置好bean就可以了，在消费消息的过程中，接受者通过实现ApplicationListener接收消息。
比如可以直接使用Spring的ScheduleTimerTask和TimerFactoryBean作为定时器定时产生消息，具体可以参见《Spring框架高级编程》。
TimerFactoryBean是一个工厂bean，对其中的ScheduleTimerTask进行处理后输出，参考ScheduleTimerTask的实现发现它最后调用的是jre的TimerTask：

    public void setRunnable(Runnable timerTask) {
        this.timerTask = new DelegatingTimerTask(timerTask);
    }

在书中给出了一个定时发送消息的例子，当然可以可以通过定时器作其他的动作，有两种方法：
1.定义MethodInvokingTimerTaskFactoryBean定义要执行的特定bean的特定方法，对需要做什么进行封装定义；
2.定义TimerTask类，通过extends TimerTask来得到，同时对需要做什么进行自定义
然后需要定义具体的定时器参数，通过配置ScheduledTimerTask中的参数和timerTask来完成，以下是它需要定义的具体属性，timerTask是在前面已经定义好的bean

    private TimerTask timerTask;

    private long delay = 0;

    private long period = 0;

    private boolean fixedRate = false;

最后，需要在ApplicationContext中注册，需要把ScheduledTimerTask配置到FactoryBean - TimerFactoryBean，这样就由IOC容器来管理定时器了。参照
TimerFactoryBean的属性，可以定制一组定时器。

public class TimerFactoryBean implements FactoryBean, InitializingBean, DisposableBean {

    protected final Log logger = LogFactory.getLog(getClass());

    private ScheduledTimerTask[] scheduledTimerTasks;

    private boolean daemon = false;

    private Timer timer;

    ...........
}

如果要发送时间我们只需要在定义好的ScheduledTimerTasks中publish定义好的事件就可以了。具体可以参考书中例子的实现，这里只是结合FactoryBean的原理做一些解释。如果结合事件和定时器机制，我们可以很方便的实现heartbeat(看门狗），书中给出了这个例子，这个例子实际上结合了Spring事件和定时机制的使用两个方面的知识 - 当然了还有IOC容器的知识（任何Spring应用我想都逃不掉IOC的魔爪：）

评论

54 楼 xuehongliang 2007-08-04  

学习学习

53 楼 jiwenke 2007-07-05  

bennyparlo 写道

没错,既然getBean了,那就按需要的bean去加载.所以与预实例化没有关系.

换句话说,ApplicatonContext在容器启动时进行预实例化操作.而BeanFactory在getBean的时候进,如果有必要则行进行预实例化,而且仅仅对于顶层的bean.

这样看来这种预实例化实际上是上下文对IOC容器使用的一种优化，提高容器getBean的性能，了解了IOC容器的原理，可以在很多地方扩展和加强 - 比如提高IOC容器的容量和性能方面。

52 楼 bennyparlo 2007-07-04  

没错,既然getBean了,那就按需要的bean去加载.所以与预实例化没有关系.

换句话说,ApplicatonContext在容器启动时进行预实例化操作.而BeanFactory在getBean的时候进,如果有必要则行进行预实例化,而且仅仅对于顶层的bean.

51 楼 jiwenke 2007-07-04  

jiwenke 写道

在DefaultListableBeanFactory中，

    public void preInstantiateSingletons() throws BeansException {
        if (logger.isInfoEnabled()) {
            logger.info("Pre-instantiating singletons in factory [" + this + "]");
        }

        //这里迭代所有的bean定义

        for (Iterator it = this.beanDefinitionNames.iterator(); it.hasNext();) {
            String beanName = (String) it.next();
            if (!containsSingleton(beanName) && containsBeanDefinition(beanName)) {
                RootBeanDefinition bd = getMergedBeanDefinition(beanName, false);


                //预实例化只对singleton和lazy-init设为false的bean起作用

                //而实际的预实例化就是在容器启动的过程就把依赖注入，而不是等到用户要求的时候

                //调用getBean,和用户第一次要求的时候处理是一样的

                if (!bd.isAbstract() && bd.isSingleton() && !bd.isLazyInit()) {
                    Class beanClass = resolveBeanClass(bd, beanName);
                    if (beanClass != null && FactoryBean.class.isAssignableFrom(beanClass)) {
                        getBean(FACTORY_BEAN_PREFIX + beanName);
                    }
                    else {
                        getBean(beanName);
                    }
                }
            }
        }
    }

补充一点，因为预实例化是通过getBean完成的，也就是说一串依赖链只是做一次判断，只要顶层的bean是单例并且需要预实例化，那么这一串依赖bean链都会被实例化并且依赖注入完成预实例化，和它的依赖bean是否设置lazy-init没有关系 - 因为在getBean是BeanFactory的方法，不会处理这个lazy-init属性，同时也说明在使用XmlBeanFactory这样的BeanFactory的时候，这个配置属性是不起作用的。
在Spring2.0的reference guide中也提到了这一点：
One thing to understand about lazy-initialization is that even though a bean definition may be marked up as being lazy-initialized, if the lazy-initialized bean is the dependency of a singleton bean that is not lazy-initialized, when the ApplicationContext is eagerly pre-instantiating the singleton, it will have to satisfy all of the singletons dependencies, one of which will be the lazy-initialized bean! So don't be confused if the IoC container creates one of the beans that you have explicitly configured as lazy-initialized at startup; all that means is that the lazy-initialized bean is being injected into a non-lazy-initialized singleton bean elsewhere.

50 楼 bennyparlo 2007-07-03  

也就是说,BeanFactory提供了这个接口,但并非作为模板给他自己的实现所使用,而提供给携带DefaultListableBeanFactory的AbstractRefreshableApplicationContext来使用.同时也想纠正个许多参考书上所说的ApplicationContext完全集成了BeanFactory的说法.虽然讲ApplicationContext也同样实现了BeanFactory所实现的众多接口,但是从设计模式的角度来将,可以类似把ApplicationContext是BeanFactory的代理,也就是说ApplicationContext将bean定义的加载和请求委托给了BeanFactory外,同时还实现了周边额外的处理,当然这个处理主要还出于spring在其他容器或环境中的使用.当然主要还是正对j2ee场景下的使用.

49 楼 jiwenke 2007-07-03  

bennyparlo 写道

没错,可以参考spring reference中的1段说明:

3.3. 属性，合作者，自动装配和依赖检查
3.3.1. 设置bean的属性和合作者
................

通常你可以信任Spring做了正确的事情。它会在BeanFactory装载的时候检查出错误，包括对不存在bean的引用和循环引用。它会尽可能晚地设置属性和解决依赖（比如创建那些需要的依赖），也就是在bean真正被创建的时候。这就意味着：就算一个BeanFactory被正确地装载，稍后当你请求一个bean的时候，如果创建那个bean或者它的依赖的时候出现了错误，这个BeanFactory也会抛出一个异常。比如，如果一个bean抛出一个异常作为缺少或非法属性的结果，这样的情况就会发生。这种潜在地推迟一些配置错误可见性的行为正是ApplicationContext默认预实例化singleton bean的原因。以前期的时间和内存为代价在beans真正需要之前创建它们，你就可以在ApplicationContext创建的时候找出配置错误，而不是在后来。如果你愿意，你也可以覆盖这种默认的行为，设置这些singleton bean为lazy-load（不是预实例化的）。





这里是翻译版的原文.应该可以对应你说的这段了.

呵呵，把代码找出来，验证一下，这里涉及到一个预实例化的问题，也是BeanFactory和上下文使用的一个区别，也牵涉到一个bean定义属性lazy-init的使用：
我们记得在在上下文初始化的时候会通过refresh来完成 - 在AbstractApplicationContext中：

    public void refresh() throws BeansException, IllegalStateException {
        synchronized (this.startupShutdownMonitor) {

            // 这里是定位，读入，解析和注册bean定义的地方
            refreshBeanFactory();
            .......


            try {
                ........
                // 这里是对bean作预实例化的地方，也是lazy-init属性起作用的地方
                beanFactory.preInstantiateSingletons();

                // Last step: publish corresponding event.
                publishEvent(new ContextRefreshedEvent(this));
            }

            catch (BeansException ex) {
                // Destroy already created singletons to avoid dangling resources.
                beanFactory.destroySingletons();
                throw ex;
            }
        }
    }

在DefaultListableBeanFactory中，

    public void preInstantiateSingletons() throws BeansException {
        if (logger.isInfoEnabled()) {
            logger.info("Pre-instantiating singletons in factory [" + this + "]");
        }

        //这里迭代所有的bean定义

        for (Iterator it = this.beanDefinitionNames.iterator(); it.hasNext();) {
            String beanName = (String) it.next();
            if (!containsSingleton(beanName) && containsBeanDefinition(beanName)) {
                RootBeanDefinition bd = getMergedBeanDefinition(beanName, false);


                //预实例化只对singleton和lazy-init设为false的bean起作用

                //而实际的预实例化就是在容器启动的过程就把依赖注入，而不是等到用户要求的时候

                //调用getBean,和用户第一次要求的时候处理是一样的

                if (!bd.isAbstract() && bd.isSingleton() && !bd.isLazyInit()) {
                    Class beanClass = resolveBeanClass(bd, beanName);
                    if (beanClass != null && FactoryBean.class.isAssignableFrom(beanClass)) {
                        getBean(FACTORY_BEAN_PREFIX + beanName);
                    }
                    else {
                        getBean(beanName);
                    }
                }
            }
        }
    }

而这个lazy-init的属性是在BeanDefinitionParserDelegate中设置的，但值得注意的是这里只作设置不做处理，处理要放到预实例化中去作。

    public AbstractBeanDefinition parseBeanDefinitionElement(
            Element ele, String beanName, BeanDefinition containingBean) {
            ........

            //这里取得属性值，在bean定义文件中

            String lazyInit = ele.getAttribute(LAZY_INIT_ATTRIBUTE);

            //如果是默认的值并且这个bean是单例，设为false

            if (DEFAULT_VALUE.equals(lazyInit) && bd.isSingleton()) {
                // Just apply default to singletons, as lazy-init has no meaning for prototypes.
                lazyInit = getDefaultLazyInit();
            }

            //否则设为true

            bd.setLazyInit(TRUE_VALUE.equals(lazyInit));

            ........

    }

需要注意的是，getBean是BeanFactory的接口方法，而这里的调用都是在上下文中的。

48 楼 bennyparlo 2007-07-03  

jiwenke 写道

jiwenke 写道

关于lazy-init的属性，实际上是关于预实例化过程的，在bean载入定义信息的时候，实际上做的是预实例化工作

这里的理解有误，预实例化不是在loadBeanDefinition中完成的，是在上下文在refresh中完成，loadBeanDefinition是在refreshBeanFactory中，而对这个预实例化的过程是在preInitiant...中完成的。这样看来，预实例化是上下文对IOC容器的一种增强，而普通的IOC容器不去完成预实例化 - 也就是说对依赖的注入需要用户手动的去触发。这也是推荐使用上下文的原因。这个预实例化可以在一定程度上提高getBean的性能 - 当然以牺牲启动性能为前提。

没错,可以参考spring reference中的1段说明:

3.3. 属性，合作者，自动装配和依赖检查
3.3.1. 设置bean的属性和合作者
................

通常你可以信任Spring做了正确的事情。它会在BeanFactory装载的时候检查出错误，包括对不存在bean的引用和循环引用。它会尽可能晚地设置属性和解决依赖（比如创建那些需要的依赖），也就是在bean真正被创建的时候。这就意味着：就算一个BeanFactory被正确地装载，稍后当你请求一个bean的时候，如果创建那个bean或者它的依赖的时候出现了错误，这个BeanFactory也会抛出一个异常。比如，如果一个bean抛出一个异常作为缺少或非法属性的结果，这样的情况就会发生。这种潜在地推迟一些配置错误可见性的行为正是ApplicationContext默认预实例化singleton bean的原因。以前期的时间和内存为代价在beans真正需要之前创建它们，你就可以在ApplicationContext创建的时候找出配置错误，而不是在后来。如果你愿意，你也可以覆盖这种默认的行为，设置这些singleton bean为lazy-load（不是预实例化的）。





这里是翻译版的原文.应该可以对应你说的这段了.

47 楼 jiwenke 2007-07-03  

jiwenke 写道

关于lazy-init的属性，实际上是关于预实例化过程的，在bean载入定义信息的时候，实际上做的是预实例化工作

这里的理解有误，预实例化不是在loadBeanDefinition中完成的，是在上下文在refresh中完成，loadBeanDefinition是在refreshBeanFactory中，而对这个预实例化的过程是在preInitiant...中完成的。这样看来，预实例化是上下文对IOC容器的一种增强，而普通的IOC容器不去完成预实例化 - 也就是说对依赖的注入需要用户手动的去触发。这也是推荐使用上下文的原因。这个预实例化可以在一定程度上提高getBean的性能 - 当然以牺牲启动性能为前提。

46 楼 bennyparlo 2007-07-03  

candyzh 写道

就是，分析这些加载过程浪费时间，还搞得长篇大论的

关键是看它在实例化时，有没有做什么cache优化，

精神可加

呵呵,这位兄弟可能误解了我们讨论的意图,我们之所以在这里用所谓的长篇大论来研究ioc容器的启动加载工程,其目的还在于了解spring的设计思想,以便更合理有效地使用与扩展spring framwork.甚至对自己的编程思想,以及设计模式的运用都有帮助.也有可能这位兄弟已经对spring的框架很熟悉很了解,认为spring的封装已经可以用来满足绝大多数的j2ee使用场景,觉得没有必要再去了解这其中的实现细节.

45 楼 jiwenke 2007-07-03  

这个分析主要是想讨论IOC容器的工作原理和实现，如果想了解Spring IOC容器的配置和使用，有很多其他的资料和配置的说明来参考 - 仁者见仁，智者见智，在这里讨论配置使用的问题并不很合适。

44 楼 candyzh 2007-07-03  

就是，分析这些加载过程浪费时间，还搞得长篇大论的

关键是看它在实例化时，有没有做什么cache优化，

精神可加

43 楼 janh 2007-07-02  

说实话，我对spring程序具体是怎么写的并没有兴趣。
如果用到事务管理或aop的话，可能在spring启动的时候看到好多警告，说这个方法是final的因此不能被代理等，那么这些警告怎么会出来呢？
如果要做个测试，很简单，在某个单例的bean的构造方法中打印log，其他地方并不需要去调用这个bean，看看这些log什么时候打出来的。
或者等系统启动完了，断点调试一下，直接到spring的beanfactory里去看一下，创建了多少对象。

42 楼 jiwenke 2007-07-02  

janh 写道

不是吧，如果没有特殊的延迟加载的指定，对于单例对象应该是在spring初始化的时候就创建并注入的吧，对于多例的对象才在用户请求的时候才创建。

关于lazy-init的属性，实际上是关于预实例化过程的，在bean载入定义信息的时候，实际上做的是预实例化工作 - 通过预实例化的工作，容器可以尽早的发现bean依赖配置的问题，而不是要等到容器实际需要获取bean并注入依赖的时候。在这种情况下，上下文和做预实例化singleton bean,这里只是简单的解析并生成它依赖的bean的JAVA对象 - 而这个lazy-init属性就是控制这个预实例过程的属性，如果是false这进行预实例处理，如果是true那就不进行预实例处理。默认的属性是false.

41 楼 jiwenke 2007-07-02  

bennyparlo 写道

对的,目前我只看到对于单例模式的bean,在getBean时候去进行校验是否已经创建,而并没有看到在容器启动时候进行加载,而对于lazy-init=true是指如果该bean显式或隐式定义为单例的话,那么按照这样的推断,该bean将在被第1次请求的时候创建,而并非在容器启动时或者说被客户端请求访问前来实例化.

同意，同样的在Rod.Johnson的《Professional JAVA Development with Spring Framework>> 中文译本P.38中也提到这这个 - 译文如下：
向容器请求bean触发了bean的创建和初始化，包括前述的依赖注入阶段。依赖注入步骤可以触发其他BEAN（第一个bean的依赖）的创建，这样下去，创建了相关对象实例的整个图。
嘿嘿，描述得经典........

40 楼 bennyparlo 2007-07-02  

对的,目前我只看到对于单例模式的bean,在getBean时候去进行校验是否已经创建,而并没有看到在容器启动时候进行加载,而对于lazy-init=true是指如果该bean显式或隐式定义为单例的话,那么按照这样的推断,该bean将在被第1次请求的时候创建,而并非在容器启动时或者说被客户端请求访问前来实例化.

至于依赖检查,这里我比较混淆,因为我在多处看到了容器对依赖检查的处理.比如在创建BeanDefiniton和createBean的时候.

39 楼 jiwenke 2007-07-02  

bennyparlo 写道

没错,janh说得也正是我所忽略的部分.我想目前所欠缺的还有对依赖检查的处理和singleton bean的加载方式.当然我们会继续来探讨.因为在目前spring ioc的使用过程中,对singleton bean的使用也占据了很大的比重,所以有必要研究.

依赖检查具体指哪一部分？我看到在getbean中主要的处理过程是这样的：
1.检查缓存中是不是已经有了需要的bean
2.检查是不是需要在父工厂去生成bean
3.对单件bean的生成处理
4.对Prototype bean的生成处理，和单件bean不同的地方在每次都要create

我觉得对singleton和prototype的bean的处理生成和依赖注入都是在getBean的时候完成的，启动的时候不做这些处理。是不是和所谓的延迟加载有关系，现在还不太清楚。

另外，对FactoryBean的处理，包含在以下的方法中。

protected Object getObjectForBeanInstance(Object beanInstance, String name, RootBeanDefinition mbd)
            throws BeansException {

        String beanName = transformedBeanName(name);

        // Don't let calling code try to dereference the
        // bean factory if the bean isn't a factory.
        if (BeanFactoryUtils.isFactoryDereference(name) && !(beanInstance instanceof FactoryBean)) {
            throw new BeanIsNotAFactoryException(beanName, beanInstance.getClass());
        }

        boolean shared = (mbd == null || mbd.isSingleton());
        Object object = beanInstance;

        // Now we have the bean instance, which may be a normal bean or a FactoryBean.
        // If it's a FactoryBean, we use it to create a bean instance, unless the
        // caller actually wants a reference to the factory.
        // 如果需要从一个FactoryBean去getBean的话，不能直接返回这个FactoryBean，需要另外生成一个bean作为产出
        if (beanInstance instanceof FactoryBean) {
            if (!BeanFactoryUtils.isFactoryDereference(name)) {
                // Return bean instance from factory.
                // 这里会调用FactoryBean的getObject方法，当然前提是已经确认这里是一个FactoryBean
                FactoryBean factory = (FactoryBean) beanInstance;
                if (logger.isDebugEnabled()) {
                    logger.debug("Bean with name '" + beanName + "' is a factory bean");
                }
                // Cache object obtained from FactoryBean if it is a singleton.
                // 从FactoryBean中去取生成的bean,同样的需要先看看缓存中是不是已经有，注意这个缓存是FactoryBean的缓存，而FactoryBean本身可以在容器的bean缓存中
                if (shared && factory.isSingleton()) {
                    synchronized (this.factoryBeanObjectCache) {
                        object = this.factoryBeanObjectCache.get(beanName);
                        if (object == null) {
                            //这个方法调用了FactoryBean的getObject去返回需要到的bean，具体factory的实例需要实现FactoryBean的getObjet接口
                            object = getObjectFromFactoryBean(factory, beanName, mbd);
                            this.factoryBeanObjectCache.put(beanName, object);
                        }
                    }
                }
                else {
                    //如果不是单件的bean获取，每次都需要从FactoryBean中去生成需要的bean
                    object = getObjectFromFactoryBean(factory, beanName, mbd);
                }
            }
            else {
                 // The user wants the factory itself.
                if (logger.isDebugEnabled()) {
                    logger.debug("Calling code asked for FactoryBean instance for name '" + beanName + "'");
                }
            }
        }

        return object;
    }

38 楼 bennyparlo 2007-07-01  

没错,janh说得也正是我所忽略的部分.我想目前所欠缺的还有对依赖检查的处理和singleton bean的加载方式.当然我们会继续来探讨.因为在目前spring ioc的使用过程中,对singleton bean的使用也占据了很大的比重,所以有必要研究.

37 楼 jiwenke 2007-07-01  

janh 写道

不是吧，如果没有特殊的延迟加载的指定，对于单例对象应该是在spring初始化的时候就创建并注入的吧，对于多例的对象才在用户请求的时候才创建。

确实没有考虑这个属性的处理，不太清楚这个延迟属性对加载的影响，但我觉得整个加载和创建注入的过程还是比较清楚的。

janh 写道

对于单例对象应该是在spring初始化的时候就创建并注入的吧，对于多例的对象才在用户请求的时候才创建。

你说的多例是不是指protoype类型？
能不能举些代码的例子来说明一下 - 大家一起研究研究？毕竟执行的代码是最明白的。

36 楼 janh 2007-07-01  

jiwenke 写道

bennyparlo 写道

最后来总结下吧,对于普通ioc容器启动到被客户端使用的步骤大致如下:

定义->定位->装载->注册->创建->注入

呵呵，脉络很清楚了，补充一点：
在容器启动的时候完成：定义 -〉定位 -〉装载
在客户向容器要求bean的时候完成： 创建 -〉注入

不是吧，如果没有特殊的延迟加载的指定，对于单例对象应该是在spring初始化的时候就创建并注入的吧，对于多例的对象才在用户请求的时候才创建。

35 楼 jiwenke 2007-07-01  

bennyparlo 写道

最后来总结下吧,对于普通ioc容器启动到被客户端使用的步骤大致如下:

定义->定位->装载->注册->创建->注入

呵呵，脉络很清楚了，补充一点：
在容器启动的时候完成：定义 -〉定位 -〉装载
在客户向容器要求bean的时候完成： 创建 -〉注入