ioc，大名鼎鼎，如雷贯耳。官方给的定义是依赖注入（dependency injection）或者控制反转（inversion of control），都相当术语化，不太容易懂。
想象下日常中的生产过程，在生产之前是客户下单，单子上会详细注明需要的产品，包括产品的各方面规格属性，然后工厂据此生产。
ioc就是一个类似的过程，我们声明需要什么，工厂据此给我们生产出来。在这个过程中我们只是给出了需求清单，而不用再去辛苦new，以及不停设置各种属性。
spring-beans是ioc最著名的实现，而且没有之一，在业界几乎也就是ioc的代名词。beans是整个spring的基石组件，可以说所有的spring组件都是基于它。
spring-beans提供的优秀的可扩展能力使spring几乎能包容一切，用户只需遵循spring beans的相关规范--spring.schema定义配置文档的文法规范，spring.handler定义客户化配置的解析工具--就可以将bean接入到spring容器里。bean接入后还可以通过实现beanpostprocessor或者init-method对bean做后处理甚至替换bean。
spring-beans的优秀设计使spring越来越像是一个生态圈，基于beans，aop、context、mvc、annotation等强大的组件都被接入进来，除此还有一些优秀的第三方组件，例如dubbo等。
以aop为例，先在parse阶段对aop的配置生成advised bean（advisor），然后在所有bean的后处理阶段get advised bean，并通过filter判断是否适应于当前bean，适用则会对bean织入advice。后面如果有时间会专门做篇aop，这里不再继续深入。
dubbo和aop略有区别，dubbo的扩展选择了init method中的afterpropertiesset，所有严格意义上dubbo是无法去spring的，虽然dubbo声明是可以，但其实只能不适用spring功能，而不能去spring jar，dubbo bean在init阶段生成ref，其实也是个代理--封装了远程访问的细节。
spring-beans的核心实体是beandefinition和beanfactory。前者映射我们的定义，后者则是依据定义生产bean的工厂。
上图是spring beans的静态结构图，更多是偏重于bean解析，因为1. 理解了bean解析也就理解了一半spring扩展能力；2.beanfactory的复杂不在于类之间的组织结构，而在于复杂的调用链路，也就没必要是静态结构方面做过多说明。需要说明的是，这只是概念模型，并不完全映射到类，因为spring的抽象层次太高，一个概念实体功能往往由多个类协同完成，画起来比较费劲，就类似beanfactory，光搞清楚各个beanfactory之间的关系就理得头痛，所以都尽可能从概念层面说明。
defaultlistablebeanfactory是beandefintionregistry的默认实现，它是个适配器，用于适配beanfactory和beandefintionregistry，工厂和定义通过它统一。它由applicationcontext初始化，并被作为beandefinitionreader的registry。reader对配置文档加载解析，生成definition并注册到registry--其实就是defaultlistablebeanfactory，这样工厂就拥有了类定义，bean初始化时也可以通过内部方法轻松获取到定义。
namespacehandlerresolver用于获取配置解析实体--namespacehandler。它和registry均内聚在上下文实体--readercontext中，parser内聚上下文从而可以间接访问handler和registry获得解析和注册的能力。
其他几个实体都比较直观便于理解，不再一一赘述。
beandefinitionreader是整个bean解析的聚合根，它由applicationcontext创建，并将defaultlistablebeanfactory作为registry传递给它。
beandefinitionreader创建文档读取实体--docuemntreader用于加载解析，并在step3加载文档时创建上下文--readercontext传递给文档读取实体。上下文贯穿于整个解析过程始终，它在文档读取实体使用parser解析时也会被传入parser中。
parse过程是整个加载过程的核心，默认parser通过间接关联的识别器可以依据不同配置节点进行parser切换，当读到非默认配置时，则切换到对应客户化parser解析。解析完成后再通过间接关联的registry进行注册，从而配置定义进入spring管理，待getbean时使用。
客户化配置是spring非常重要的扩展点，spring强大的扩展能力有一半功能要归功于它，另一半中的80%就是后面要介绍的大名鼎鼎的beanpostprocessor。不仅仅一些第三方扩展（例如开篇提到的dubbo）基于它，spring本身的很多模块也是基于它，例如spring-aop，spring-context等等，spring体系内除了默认的beans命名空间其余都基于它扩展的。
namespacehandlerresolver由beandefinitionreader初始化，后者在第一次被访问时读取spring.handlers文件。.handlers文件定义namespace uri和对应处理类的映射关系。例如：
上面的这行配置就是配置声明的解析类。
namespacehandlerresolver依据节点namespace获得namespacehandler，然后使用handler处理自定义配置节点。
init方法注册localname和自定义parser的关系，parser和localname的关系由handler的提供者自己注册。例如：
上面就是aop注册parser的代码片段。config，aspectj-autoproxy这些就是localname，parse过程中不同的localname会切换到不同的parser解析。
spring先通过命名空间定位到handler，handler处理时再基于localname取相应的parser解析当前结点。比如这个配置，aop是命名空间，aspectj-autoproxy是localname。整个读取解析过程中先通过aop找到aopnamespacehandler，再在解析到aspectj-autoproxy节点时使用aspectjautoproxybeandefinitionparser来解析。如果要研究spring源码，一定要先找到对应parser，知道每个配置项对应到运行时的bean结构才能更好理解spring；而且parser可能会生成一些默认的beanpostprocessor，如果意识不到这些后处理器，那么对代码的读取将会断片，陷入完全无法理解的境地。比如spring-aop就是由parser默认生成aopautoproxycreator这个beanpostprocessor，在bean初始化后由这个processor对bean生成代理。
上图是getbean过程，整个过程很简洁，实际深入代码会发现非常繁琐。
beanfactory和beandefinitionregistry在spring里是统一的，参见第一节，图上为了方便理解，拆成两个概念实体。
需要注意的是第4步和第6步，bean配置时可以指定parent属性，如果有parent，则beanfactory会对local和parent做merge，merge的策略是对parent做覆盖，也可以理解为是对parent做继承。这和parent bean factory完全是两个概念，一定要区分开。
在beans的实体静态结构里，分别注明了parent bean definition和parent bean factory。两者都是被关联的，而不是被继承。后者有点像jvm的双亲委托模型，parent和child有各自的上下文，类似于jvm的命名空间。parent bean factory由applicationcontext设置，无法配置。比如spring mvc就是两个父子两个容器，在容器refresh时相应的也会把父容器的beanfactory设置成子容器beanfactory的parentbeanfactory。
bean主要经过instantiate，populate，initializebean和registerdisposablebean4个状态，在状态流转中会调用很多spring预留的扩展接口。
awaremethod
如果bean继承了beanfactoryaware，beannameaware，beanclassloaderaware，则会在initialize阶段将beanfactory, beanname和bean classloader设置给bean。
注意它和applicationcontextaware是不一样的，后者是由beanpostprocessor做后处理set的。
init method
method不仅仅包括配置的init-method方法还包括initializedbean的afterpropertiesset回调接口，这两者均是无参的，完全可以互相替代，两者中afterpropertiesset调用在前。
上文提到过，spring另一半的扩展能力是由beanpostprocessor提供的。先看下其接口定义
两个方法分别在init-method调用前后，对bean做后处理。需要特别注意的就是postprocessafterinitialization，大部分的spring扩展就是由它来完成的，比如上文提到的aop就是在这个阶段对bean做后处理生成代理。相应的也可以使用postprocessbeforeinitialization，但是此时init-method并未执行，后处理需要保证init-method带来的影响，@postconstruct的方法执行就是在这个阶段。
instantiationawarebeanpostprocessor继承了beanpostprocessor，主要用于在bean实例化前后做处理。
实例化前处理，这个方法的参数是beanclass和beanname，在bean实例化前调用，如果这个方法的返回值不为空则getbean结束，用户收到的就是这个该方法的返回值。这个扩展点主要是留给预处理的，用户可以直接生成一个同类型的bean，替换实际bean，此时实际bean不会被实例化。
实例化后处理连同属性后处理是spring内部非常重要的扩展点，annotation的field注入就是在这两个阶段完成。主要有两个关键实现：
commonannotationbeanpostprocessor，该类在实例化后处理阶段做属性注入，主要用于@resource
autowiredannotationbeanpostprocessor，该类在属性后处理阶段做属性注入，主要用于@autowired
前者还继承了initdestroyannotationbeanpostprocessor类，该类会在init-method被执行前调用@postconstruct方法。