BeanFactory总览

BeanFactory接口是Spring IoC的基础。它的特定契约主要用于与Spring的其他部分以及相关的第三方框架集成，它的“DefaultListableBeanFactory”实现是高级“GenericApplicationContext”容器中的一个关键委托。

“BeanFactory”和相关接口(如“BeanFactoryAware”、“InitializingBean”、“DisposableBean”)是其他框架组件的重要集成点:不需要任何注解甚至反射，它们允许容器及其组件之间非常高效的交互。应用程序级bean可能使用相同的回调接口，但通常更喜欢声明性依赖注入，通过注解或编程配置。

请注意，核心的“BeanFactory”API级别及其“DefaultListableBeanFactory”实现对配置格式或要使用的任何组件注释不做任何假设。所有这些功能都是通过诸如“XmlBeanDefinitionReader”和“AutowiredAnnotationBeanPostProcessor”等扩展来实现的，这些扩展在作为核心元数据表示的共享“BeanDefinition”对象上运行。这就是使Spring容器如此灵活和可扩展的本质。

BeanFactory接口体系

如果bean name配置为单例,应用内只会获取到一个实例.如果配置为原型,那么可以实例化好后填充属性(基于用户的配置).

BeanFactory需要管理bean的生命周期,比如初始化时需要按顺序实现如下接口:

1. BeanNameAware's {@code setBeanName}
2. BeanClassLoaderAware's {@code setBeanClassLoader}
3. BeanFactoryAware's {@code setBeanFactory}
4. ResourceLoaderAware's {@code setResourceLoader}仅对application context有效
5. ApplicationEventPublisherAware's {@code setApplicationEventPublisher}仅对application context有效
6. MessageSourceAware's {@code setMessageSource}仅对application context有效
7. ApplicationContextAware's {@code setApplicationContext}仅对application context有效
8. ServletContextAware's {@code setServletContext}仅对application context有效
9. {@code postProcessBeforeInitialization} methods of BeanPostProcessors
10. InitializingBean's {@code afterPropertiesSet}
11. a custom init-method definition xml中配置的init-method
12. {@code postProcessAfterInitialization} methods of BeanPostProcessors

还有关闭容器的接口:

1. DisposableBean's {@code destroy}
2. a custom destroy-method definition xml配置中的destroy-method

接口里定义了一个变量String FACTORY_BEAN_PREFIX = "&"; 这是用来区分是获取FactoryBean还是FactoryBean的createBean创建的实例.如果&开始则获取FactoryBean;否则获取createBean创建的实例.

BeanFactory接口方法

总结：
1、4个获取实例的方法。getBean的重载方法。
2、4个判断的方法。判断是否存在，是否为单例、原型，名称类型是否匹配。
3、1个获取类型的方法、一个获取别名的方法。根据名称获取类型、根据名称获取别名。一目了然！
这10个方法，很明显，这是一个典型的工厂模式的工厂接口。

2. AutowireCapableBeanFactory

在BeanFactory基础上实现对已存在实例的管理.

可以使用这个接口集成其它框架, 捆绑并填充并不由Spring管理生命周期并已存在的实例.像集成WebWork的Actions 和Tapestry Page就很实用.

一般应用开发者不会使用这个接口,所以像ApplicationContext这样的外观实现类不会实现这个接口,如果真手痒痒可以通过ApplicationContext的getAutowireCapableBeanFactory接口获取.

这边定义了5种自动装配策略:不注入AUTOWIRE_NO,使用bean name策略装配AUTOWIRE_BY_NAME,使用类型装配策略AUTOWIRE_BY_TYPE,使用构造器装配策略AUTOWIRE_CONSTRUCTOR,自动装配策略AUTOWIRE_AUTODETECT

这边的自动策略是先尝试构造器,然后才是byType.这边应该是跟xml配置文件中的装配策略对应.

AutowireCapableBeanFactory定义的方法:

ListableBeanFactory

ListableBeanFactory是BeanFactory接口的扩展，bean工厂可以枚举所有bean实例，而不是根据客户的请求逐一查找。需要预加载所有bean定义（例如基于xml的工厂）的BeanFactory实现可以实现这个接口。

这个接口中的方法仅仅关注此工厂内部的bean定义，会会忽略任何被像ConfigurableBeanFactory的registerSingleton方法已注册的单例的bean。getBeanNamesOfType和getBeansOfType例外，但也会手动的检查已被注册的单例bean。当然，BeanFactory的getBean方法也可以透明的访问这些特殊的bean（已被注册的单例bean）。然而，在一般的场合，无论如何，所有bean都会被外部定义，所以许多程序不需要考虑这方面区别。

注意: getBeanDefinitionCount和containsBeanDefinition的实现方法因为效率比较低,还是少用为好.

总结：
1、总共5个静态不可变常量来指明装配策略，其中一个常量被Spring3.0废弃、一个常量表示没有自动装配，另外3个常量指明不同的装配策略——根据名称、根据类型、根据构造方法。
2、9个跟自动装配有关的方法，实在是繁杂，具体的意义我们研究类的时候再分辨吧。
3、2个执行BeanPostProcessors的方法。
4、3个分解指定依赖的方法
这个工厂接口继承自BeanFacotory，它扩展了自动装配的功能，根据类定义BeanDefinition装配Bean、执行前、后处理器等。

ListableBeanFactory方法

HierarchicalBeanFactory

提供父容器的访问功能.至于父容器的设置,需要找ConfigurableBeanFactory的setParentBeanFactory(接口把设置跟获取给拆开了!)。

HierarchicalBeanFactory方法

ConfigurableBeanFactory

ConfigurableBeanFactory定义BeanFactory的配置.ConfigurableBeanFactory中定义了太多太多的api,比如类加载器,类型转化,属性编辑器,BeanPostProcessor,作用域,bean定义,处理bean依赖关系,合并其他ConfigurableBeanFactory,bean如何销毁.

ConfigurableBeanFactory同时继承了HierarchicalBeanFactory 和 SingletonBeanRegistry 这两个接口，即同时继承了分层和单例类注册的功能。

ConfigurableBeanFactory方法

分类：
1、2个静态不可变常量分别代表单例类和原型类。
2、1个设置父工厂的方法，跟HierarchicalBeanFactory接口的getParentBeanFactory方法互补。
3、4个跟类加载器有关的方法：get/set工厂类加载器和get/set临时类加载器。
4、2个设置、是否缓存元数据的方法（热加载开关）。
5、11个处理Bean注册、加载等细节的方法，包括：Bean表达式分解器、转换服务、属性编辑登记员、属性编辑器、属性编辑注册器、类型转换器、嵌入式的字符串分解器
6、2个处理Bean后处理器的方法。
7、3个跟注册范围相关的方法。
8、1个返回安全访问上下文的方法、1个从其他的工厂复制相关的所有配置的方法。
9、2个跟Bean别名相关的方法、1个返回合并后的Bean定义的方法。
10、1个判断是否为工厂Bean的方法、2个跟当前Bean创建时机相关的方法。
11、3个跟Bean依赖相关的方法、3个销毁Bean相关的方法。
SingletonBeanRegistry 这两个接口，并额外独有38个方法！这38个方法包含了工厂创建、注册一个Bean的众多细节。这个工厂名为ConfigurableBeanFactory，真是名不虚传！统计一下此时的ConfigurableBeanFactory的方法数吧。自有的37个方法、HierarchicalBeanFactory的2个方法、SingletonBeanRegistry的5个方法、爷爷接口BeanFactory的10个方法，共有54个方法！虽然方法繁多，还算井井有条！

ConfigurableListableBeanFactory

提供bean definition的解析,注册功能,再对单例来个预加载(解决循环依赖问题).

貌似我们一般开发就会直接定义这么个接口了事.而不是像Spring这样先根据使用情况细分那么多,到这边再合并

ConfigurableListableBeanFactory方法

具体：
1、2个忽略自动装配的的方法。
2、1个注册一个可分解依赖的方法。
3、1个判断指定的Bean是否有资格作为自动装配的候选者的方法。
4、1个根据指定bean名，返回注册的Bean定义的方法。
5、2个冻结所有的Bean配置相关的方法。
6、1个使所有的非延迟加载的单例类都实例化的方法。
7、1个返回所有bean name的迭代器方法
8、1个清除元数据缓存的方法
总结：工厂接口ConfigurableListableBeanFactory同时继承了3个接口，ListableBeanFactory、AutowireCapableBeanFactory 和 ConfigurableBeanFactory，扩展之后，加上自有的这8个方法，这个工厂接口总共有83个方法，实在是巨大到不行了。这个工厂接口的自有方法总体上只是对父类接口功能的补充，包含了BeanFactory体系目前的所有方法，可以说是接口的集大成者。

BeanFactory or ApplicationContext?

尽量使用‘ApplicationContext’除非你有很好的理由不这样做，使用‘GenericApplicationContext’和它的子类‘AnnotationConfigApplicationContext’作为通用的自定义引导实现。这些是Spring核心容器的主要入口点，用于所有常见目的:加载配置文件、触发类路径扫描、以编程方式注册bean定义和带注释的类。

因为“ApplicationContext”包含“BeanFactory”的所有功能，所以通常建议使用它而不是普通的“BeanFactory”，除非是需要对bean处理进行完全控制的场景。在‘ApplicationContext’(如‘GenericApplicationContext’实现)中，有几种类型的bean将被约定(即通过bean名称或bean类型)检测，特别是后处理器，而普通的‘DefaultListableBeanFactory’与任何特殊bean无关。

对于许多扩展容器特性，如注释处理和AOP代理，' BeanPostProcessor '扩展点是必不可少的。如果你只使用一个普通的“DefaultListableBeanFactory”，这样的后处理器在默认情况下不会被检测和激活。这种情况可能令人困惑，因为您的bean配置实际上没有任何问题；在这种情况下，需要通过额外的设置完全引导容器。

下表列出了“BeanFactory”和“ApplicationContext”接口和实现提供的功能

要显式地将bean后处理器注册到DefaultListableBeanFactory，您需要以编程方式调用addBeanPostProcessor:

DefaultListableBeanFactory factory = new DefaultListableBeanFactory();
// populate the factory with bean definitions

// now register any needed BeanPostProcessor instances
factory.addBeanPostProcessor(new AutowiredAnnotationBeanPostProcessor());
factory.addBeanPostProcessor(new MyBeanPostProcessor());

// now start using the factory

要将' BeanFactoryPostProcessor '应用到普通的' DefaultListableBeanFactory '上，需要调用其' postProcessBeanFactory '方法:

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

// bring in some property values from a Properties file
PropertyPlaceholderConfigurer cfg = new PropertyPlaceholderConfigurer();
cfg.setLocation(new FileSystemResource("jdbc.properties"));

// now actually do the replacement
cfg.postProcessBeanFactory(factory);

在这两种情况下，显式注册步骤都不方便，这就是为什么在spring支持的应用程序中，各种“ApplicationContext”变体比普通的“defaultlistablebeanfactory”更受青睐的原因，特别是在典型的企业设置中依赖“BeanFactoryPostProcessor”和“BeanPostProcessor”实现扩展容器功能时更是如此。

一个“AnnotationConfigApplicationContext”具有所有现成注册的通用注释后处理器，并且可以通过配置注释(如“@EnableTransactionManagement”)在幕后引入额外的处理器。在Spring基于注释的配置模型的抽象级别上，bean后处理器的概念仅仅是一个内部容器细节。