Bean从生到死
阅读开源框架源码，最忌讳一开始就陷入到代码细节中。
比较推荐的做法是，先了解整个框架的大致结构，主线的主要流程，然后再从源码中找到对应的执行路线，相互验证。
Spring中最核心的就是IOC容器，而主线路就是Bean从定义到创建，再到销毁的全过程，即Bean的生命周期。
AOP其实也是在bean的生命周期过程中实现的。
可以说，Spring IOC是整个Spring的基石。
因此，我们首先必须了解Bean的生命周期，再深入研究源码
先抛开spring，如果让我们实现一个类似IOC容器的功能，我们会如何实现？
最简单的就是直接实例化对象，然后放到map中，需要的时候直接从map中取出：
我们一般使用xml文件或者注解的方式告诉容器哪些类是需要作为bean放入容器中管理，因此需要定义beanDefinition来保存bean的信息，包括bean的名称，bean的类，是否是primary等。
是否可以不要beanDefinition呢？答案是不可以。
因为bean的来源可能是xml，可能是注解，甚至可能是json配置文件，因此需要一层抽象，容器内部在构建bean时，只需对接beanDefinition，而不需要去对接具体的bean来源。
在实际开发中，bean和bean之间往往存在着依赖关系，因此在实例化之后，需要为bean自动注入所需的依赖的bean，于是就有了属性填充这一步骤：
然后进行初始化：
当bean的生命走到尽头，就需要销毁：（为了图精简好看，暂时去除单例池）
扩展点
不过Spring容器就这么简单吗？当然不是。
Spring是一个扩展性极高的框架，因为它在bean的从生到死的过程中，插入了很多扩展点
BeanFactoryPostProcessor
第一个要说的扩展点就是BeanFactoryPostProcessor，这是一个bean工厂的后置处理器，在bean工厂创建出来后，bean实例化之前调用。
开发者可以利用这个扩展点对bean工厂进行一定程度的改造
BeanDefinitionRegistryPostProcessor
BeanDefinitionRegistryPostProcessor其实是BeanFactoryPostProcessor的子接口，从命名上可以看出，这个是针对BeanDefinition的后置处理器，可以让我们修改BeanDefinition。
从执行顺序上，是先执行BeanDefinitionRegistryPostProcessor，再执行BeanFactoryPostProcessor
InstantiationAwareBeanPostProcessor
在实例化bean前后，会调用这个扩展点的postProcessBeforeInstantiation和postProcessAfterInstantiation方法
BeanPostProcessor
在初始化前后，会调用BeanPostProcessor的postProcessBeforeInitialization和postProcessAfterInitialization方法
大名鼎鼎的AOP就是在该过程中实现的
以上就是bean的完整的生命周期
