spring IOC 参禅
2 IOC注册原理
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这个接口来的：IoC容器的初始化包括BeanDefinition的Resource定位、载入和注册这三个基本的过程。注意这个时候还没有发生依赖注入，DefaultListableBeanFactory类里面有个hashMap里面存放key值就是beanName为string类型，values值就是BeanDefinition(BeanDefinition为接口，里面包含字段及方法名)。使用的时候，通过getBean方法，具体实现是doGetBean方法，通过反射将BeanDefinition转化为实例化bean。如果FactoryBean接口实现类的isSington方法返回的是true，那么每次调用getObject方法的时候会优先尝试从FactoryBean对象缓存中取目标对象，有就直接拿，没有就创建并放入FactoryBean对象缓存，这样保证了每次单例的FactoryBean调用getObject()方法后最终拿到的目标对象一定是单例的，即在内存中都是同一份；
如果FactoryBean接口实现类的isSington方法返回的是false，那么每次调用getObject方法的时候都会新创建一个目标对象。
3、Spring装配Bean的过程
1. 实例化;
2. 设置属性值;
3. 如果实现了BeanNameAware接口,调用setBeanName设置Bean的ID或者Name;
4. 如果实现BeanFactoryAware接口,调用setBeanFactory 设置BeanFactory;
5. 如果实现ApplicationContextAware,调用setApplicationContext设置ApplicationContext
6. 调用BeanPostProcessor的预先初始化方法;
7. 调用InitializingBean的afterPropertiesSet()方法;
8. 调用定制init-method方法；
9. 调用BeanPostProcessor的后初始化方法;
Spring容器关闭过程
1. 调用DisposableBean的destroy();
2. 调用定制的destroy-method方法;
4 Spring InitializingBean和init-method
Spirng的InitializingBean为bean提供了定义初始化方法的方式。InitializingBean是一个接口，它仅仅包含一个方法：afterPropertiesSet()。InitializingBean和init-method可以一起使用，Spring会先处理InitializingBean再处理init-method。Spring要求init-method是一个无参数的方法，如果init-method指定的方法中有参数，那么Spring将会抛出java.lang.NoSuchMethodException
5 spring 后置处理器BeanFactoryPostProcessor和BeanPostProcessor的用法和区别
主要区别就是： BeanFactoryPostProcessor可以修改BEAN的配置信息而BeanPostProcessor不能，
BeanPostProcessor：即当Spring容器实例化Bean实例之后进行的增强处理。
BeanFactoryPostProcessor：对容器本身进行处理，并总是在容器实例化其他任何Bean之前读取配置文件的元数据并可能修改
6 BeanFacotry与ApplicationContext
BeanFacotry是spring中比较原始的Factory。如XMLBeanFactory就是一种典型的BeanFactory。原始的BeanFactory无法支持spring的许多插件，如AOP功能、Web应用等。
ApplicationContext接口,它由BeanFactory接口派生而来，因而提供BeanFactory所有的功能。ApplicationContext以一种更向面向框架的方式工作以及对上下文进行分层和实现继承，ApplicationContext包还提供了以下的功能：
• MessageSource, 提供国际化的消息访问
• 资源访问，如URL和文件
• 事件传播
• 载入多个（有继承关系）上下文 ，使得每一个上下文都专注于一个特定的层次，比如应用的web层
6 Spring在代码中获取bean的几种方式
方法一：在初始化时保存ApplicationContext对象 方法二：通过Spring提供的utils类获取ApplicationContext对象 方法三：继承自抽象类ApplicationObjectSupport 方法四：继承自抽象类WebApplicationObjectSupport 方法五：实现接口ApplicationContextAware 方法六：通过Spring提供的ContextLoader
7 lazy-init详解
ApplicationContext实现的默认行为就是在启动时将所有singleton bean提前进行实例化（也就是依赖注入）。提前实例化意味着作为初始化过程的一部分，ApplicationContext实例会创建并配置所有的singleton bean。通常情况下这是件好事，因为这样在配置中的任何错误就会即刻被发现（否则的话可能要花几个小时甚至几天）。
（lazy-init 设置只对scop属性为singleton的bean起作用）
有时候这种默认处理可能并不是你想要的。如果你不想让一个singleton bean在ApplicationContext实现在初始化时被提前实例化，那么可以将bean设置为延迟实例化。
如果一个设置了立即加载的bean1,引用了一个延迟加载的bean2,那么bean1在容器启动时被实例化，而bean2由于被bean1引用，所以也被实例化，这种情况也符合延迟加载的bean在第一次调用时才被实例化的规则。
在容器层次中通过在
如果一个bean的scope属性为scope=“pototype“时，即使设置了lazy-init="false"，容器启动时不实例化bean，而是调用getBean方法是实例化的
另外加以说明:
.init-method属性指定初始化时执行的方法，distory-method属性指定bean销毁时执行的方法。
7 Spring-bean作用域scope详解
Spring Framework支持五种作用域（其中有三种只能用在基于web的Spring ApplicationContext）。
singleton
在每个Spring IoC容器中一个bean定义对应一个对象实例。
prototype
一个bean定义对应多个对象实例。
request
在一次HTTP请求中，一个bean定义对应一个实例；即每次HTTP请求将会有各自的bean实例，它们依据某个bean定义创建而成。该作用域仅在基于web的Spring ApplicationContext情形下有效。
session
在一个HTTP Session中，一个bean定义对应一个实例。该作用域仅在基于web的Spring ApplicationContext情形下有效。
global session
在一个全局的HTTP Session中，一个bean定义对应一个实例。典型情况下，仅在使用portlet context的时候有效。该作用域仅在基于web的Spring ApplicationContext情形下有效。
[@more@]
1.Singleton作用域
当一个bean的作用域为singleton, 那么Spring IoC容器中只会存在一个共享的bean实例，并且所有对bean的请求，只要id与该bean定义相匹配，则只会返回bean的同一实例。
换言之，当把一个bean定义设置为singlton作用域时，Spring IoC容器只会创建该bean定义的唯一实例。这个单一实例会被存储到单例缓存（singleton cache）中，并且所有针对该bean的后续请求和引用都将返回被缓存的对象实例。
下图演示了Spring的singleton作用域。
请注意Spring的singleton bean概念与“四人帮”（GoF）模式一书中定义的Singleton模式是完全不同的。经典的GoF Singleton模式中所谓的对象范围是指在每一个ClassLoader中指定class创建的实例有且仅有一个。把Spring的singleton作用域描述成一个container对应一个bean实例最为贴切。亦即，假如在单个Spring容器内定义了某个指定class的bean，那么Spring容器将会创建一个且仅有一个由该bean定义指定的类实例。
Singleton作用域是Spring中的缺省作用域。
2.Prototype
Prototype作用域的bean会导致在每次对该bean请求（将其注入到另一个bean中，或者以程序的方式调用容器的getBean()方法）时都会创建一个新的bean实例。根据经验，对所有有状态的bean应该使用prototype作用域，而对无状态的bean则应该使用singleton作用域。
下图演示了Spring的prototype作用域。请注意，典型情况下，DAO不会被配置成prototype，因为一个典型的DAO不会持有任何会话状态，因此应该使用singleton作用域。
对于prototype作用域的bean，有一点非常重要，那就是Spring不能对一个prototype bean的整个生命周期负责：容器在初始化、配置、装饰或者是装配完一个prototype实例后，将它交给客户端，随后就对该prototype实例不闻不问了。不管何种作用域，容器都会调用所有对象的初始化生命周期回调方法，而对prototype而言，任何配置好的析构生命周期回调方法都将不会被调用。清除prototype作用域的对象并释放任何prototype bean所持有的昂贵资源，都是客户端代码的职责。（让Spring容器释放被singleton作用域bean占用资源的一种可行方式是，通过使用bean的后置处理器，该处理器持有要被清除的bean的引用。）
谈及prototype作用域的bean时，在某些方面你可以将Spring容器的角色看作是Java new操作符的替代者。任何迟于该时间点的生命周期事宜都得交由客户端来处理。在Section 3.5.1, “Lifecycle接口”一节中会进一步讲述Spring IoC容器中的bean生命周期。
向后兼容性：在XML中指定生命周期作用域
如果你在bean定义文件中引用'spring-beans.dtd' DTD，要显式说明bean的生命周期作用域你必须使用"singleton"属性(记住singleton生命周期作用域是默认的)。 如果引用的是'spring-beans-2.0.dtd' DTD或者是Spring 2.0 XSD schema，那么需要使用"scope"属性(因为"singleton"属性被删除了，新的DTD和XSD文件使用"scope"属性)。
简单地说，如果你用"singleton"属性那么就必须在那个文件里引用'spring-beans.dtd' DTD。 如果你用"scope"属性那么必须 在那个文件里引用'spring-beans-2.0.dtd' DTD 或'spring-beans-2.0.xsd' XSD。
3. 其他作用域
其他作用域，即request、session以及global session仅在基于web的应用中使用（不必关心你所采用的是什么web应用框架）。
Note
下面介绍的作用域仅仅在使用基于web的Spring ApplicationContext实现（如XmlWebApplicationContext）时有用。如果在普通的Spring IoC容器中，比如像XmlBeanFactory或ClassPathXmlApplicationContext，尝试使用这些作用域，你将会得到一个IllegalStateException异常（未知的bean作用域）。
3.1. 初始化web配置
要使用request、session和 global session作用域的bean（即具有web作用域的bean），在开始设置bean定义之前，还要做少量的初始配置。请注意，假如你只想要“常规的”作用域，也就是singleton和prototype，就不需要这一额外的设置。
在目前的情况下，根据你的特定servlet环境，有多种方法来完成这一初始设置。如果你使用的是Servlet 2.4及以上的web容器，那么你仅需要在web应用的XML声明文件web.xml中增加下述ContextListener即可
org.springframework.web.context.request.RequestContextListener
如果你用的是早期版本的web容器（Servlet 2.4以前），那么你要使用一个javax.servlet.Filter的实现。请看下面的web.xml配置片段：
requestContextFilter
org.springframework.web.filter.RequestContextFilter
requestContextFilter
/*
3.2. Request作用域
考虑下面bean定义：
针对每次HTTP请求，Spring容器会根据loginAction bean定义创建一个全新的LoginAction bean实例，且该loginAction bean实例仅在当前HTTP request内有效，因此可以根据需要放心的更改所建实例的内部状态，而其他请求中根据loginAction bean定义创建的实例，将不会看到这些特定于某个请求的状态变化。当处理请求结束，request作用域的bean实例将被销毁。
3.3. Session作用域
考虑下面bean定义：
针对某个HTTP Session，Spring容器会根据userPreferences bean定义创建一个全新的userPreferences bean实例，且该userPreferences bean仅在当前HTTP Session内有效。与request作用域一样，你可以根据需要放心的更改所创建实例的内部状态，而别的HTTP Session中根据userPreferences创建的实例，将不会看到这些特定于某个HTTP Session的状态变化。当HTTP Session最终被废弃的时候，在该HTTP Session作用域内的bean也会被废弃掉。
3.4. global session作用域
考虑下面bean定义：
global session作用域类似于标准的HTTP Session作用域，不过它仅仅在基于portlet的web应用中才有意义。Portlet规范定义了全局Session的概念，它被所有构成某个portlet web应用的各种不同的portlet所共享。在global session作用域中定义的bean被限定于全局portlet Session的生命周期范围内。
请注意，假如你在编写一个标准的基于Servlet的web应用，并且定义了一个或多个具有global session作用域的bean，系统会使用标准的HTTP Session作用域，并且不会引起任何错误。
3.5. 作用域bean与依赖
能够在HTTP request或者Session（甚至自定义）作用域中定义bean固然很好，但是Spring IoC容器除了管理对象（bean）的实例化，同时还负责协作者（或者叫依赖）的实例化。如果你打算将一个Http request范围的bean注入到另一个bean中，那么需要注入一个AOP代理来替代被注入的作用域bean。也就是说，你需要注入一个代理对象，该对象具有与被代理对象一样的公共接口，而容器则可以足够智能的从相关作用域中（比如一个HTTP request）获取到真实的目标对象，并把方法调用委派给实际的对象。
不能和作用域为singleton或prototype的bean一起使用。为singleton bean创建一个scoped proxy将抛出BeanCreationException异常。
让我们看一下将相关作用域bean作为依赖的配置，配置并不复杂（只有一行），但是理解“为何这么做”以及“如何做”是很重要的。
在XML配置文件中，要创建一个作用域bean的代理，只需要在作用域bean定义里插入一个子元素即可（你可能还需要在classpath里包含CGLIB库，这样容器就能够实现基于class的代理；还可能要使用基于XSD的配置）。上述XML配置展示了“如何做”，现在讨论“为何这么做”。在作用域为request、session以及globalSession的bean定义里，为什么需要这个元素呢？下面我们从去掉元素的XML配置开始说起：
从上述配置中可以很明显的看到singleton bean userManager被注入了一个指向HTTP Session作用域bean userPreferences的引用。singleton userManager bean会被容器仅实例化一次，并且其依赖（userPreferences bean）也仅被注入一次。这意味着，userManager在理论上只会操作同一个userPreferences对象，即原先被注入的那个bean。而注入一个HTTP Session作用域的bean作为依赖，有违我们的初衷。因为我们想要的只是一个userManager对象，在它进入一个HTTP Session生命周期时，我们希望去使用一个HTTP Session的userPreferences对象。
当注入某种类型对象时，该对象实现了和UserPreferences类一样的公共接口（即UserPreferences实例）。并且不论我们底层选择了何种作用域机制（HTTP request、Session等等），容器都会足够智能的获取到真正的UserPreferences对象，因此我们需要将该对象的代理注入到userManager bean中, 而userManager bean并不会意识到它所持有的是一个指向UserPreferences引用的代理。在本例中，当UserManager实例调用了一个使用UserPreferences对象的方法时，实际调用的是代理对象的方法。随后代理对象会从HTTP Session获取真正的UserPreferences对象，并将方法调用委派给获取到的实际的UserPreferences对象。
这就是为什么当你将request、session以及globalSession作用域bean注入到协作对象中时需要如下正确而完整的配置：Java代码
4自定义作用域
在Spring 2.0中，Spring的bean作用域机制是可以扩展的。这意味着，你不仅可以使用Spring提供的预定义bean作用域； 还可以定义自己的作用域，甚至重新定义现有的作用域（不提倡这么做，而且你不能覆盖内置的singleton和prototype作用域）。
作用域由接口org.springframework.beans.factory.config.Scope定义。要将你自己的自定义作用域集成到Spring容器中，需要实现该接口。它本身非常简单，只有两个方法，分别用于底层存储机制获取和删除对象。自定义作用域可能超出了本参考手册的讨论范围，但你可以参考一下Spring提供的Scope实现，以便于去如何着手编写自己的Scope实现。
在实现一个或多个自定义Scope并测试通过之后，接下来就是如何让Spring容器识别你的新作用域。ConfigurableBeanFactory接口声明了给Spring容器注册新Scope的主要方法。（大部分随Spring一起发布的BeanFactory具体实现类都实现了该接口）；该接口的主要方法如下所示：
void registerScope(String scopeName, Scope scope);
registerScope(..)方法的第一个参数是与作用域相关的全局唯一名称；Spring容器中该名称的范例有singleton和prototype。registerScope(..)方法的第二个参数是你打算注册和使用的自定义Scope实现的一个实例。
假设你已经写好了自己的自定义Scope实现，并且已经将其进行了注册：
// note: the ThreadScope class does not exist; I made it up for the sake of this example
Scope customScope = new ThreadScope();
beanFactory.registerScope("thread", scope);
然后你就可以像下面这样创建与自定义Scope的作用域规则相吻合的bean定义了：
如果你有自己的自定义Scope实现，你不仅可以采用编程的方式注册自定义作用域，还可以使用BeanFactoryPostProcessor实现：CustomScopeConfigurer类，以声明的方式注册Scope。BeanFactoryPostProcessor接口是扩展Spring IoC容器的基本方法之一，在本章的BeanFactoryPostProcessor中将会介绍。
使用CustomScopeConfigurer，以声明方式注册自定义Scope的方法如下所示：
Java代码既允许你指定实际的Class实例作为entry的值，也可以指定实际的Scope实现类实例；详情请参见CustomScopeConfigurer类的JavaDoc。