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

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

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

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

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

精神可加

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

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

这里的理解有误，预实例化不是在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（不是预实例化的）。





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

呵呵，把代码找出来，验证一下，这里涉及到一个预实例化的问题，也是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的接口方法，而这里的调用都是在上下文中的。

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

补充一点，因为预实例化是通过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.