1.BeanFactory接口
Spring 的容器最基本的接口就是：BeanFactory。BeanFactory 负责配置、创建及管理bean。调用者只需使用getBean 方法即可获得指定bean的引用，无须关心bean 的实例化过程。即bean 实例的创建过程完全透明。
Spring框架中，一旦把一个Bean纳入到Spring IoC容器之中，这个Bean的生命周期就会交由容器进行管理，一般担当管理者角色的是BeanFactory或ApplicationContex
将Bean元数据收集装载
BeanDefinition：用于管理各种对象以及它们之间相互依赖关系的核心数据结构。
Resource：用来封装IO操作的类。
收集过程：通过refresh方法启动，包括BeanDefinition和Resource的定位、载入、注册三个基本过程。
定位：即寻找数据的过程，指对BeanDefinition的资源定位，由ResourceLoader通过统一的Resource接口完成。
载入：把用户定义好的Bean表示成IOC容器的内部数据结构，即BeanDefinition（POJO对象在IOC容器中的抽象）
注册：将BeanDefinition注入到HashMap中，IOC容器就是通过这个HahMap来管理数据。
2.ApplicationContext接口
对大部分J2EE 应用而言，获取Bean推荐使用ApplicationContext，因为其是BeanFactory 的子接口，提供了更多面向应用的功能，其常用的实现类是org.springframework.context.support.FileSystemXmlApplicationContext。
3.BeanFactory与ApplicationContext区别
- BeanFacotry延迟加载，即只有在使用到某个Bean时(调用getBean())，才对该Bean进行加载实例化，如果Bean的某一个属性没有注入，BeanFacotry加载后，直至第一次使用调用getBean方法才会抛出异常；而ApplicationContext则在初始化自身是检验，这样有利于检查所依赖属性是否注入；所以通常情况下我们选择使用 ApplicationContext。ApplicationContext则会在上下文启动后预载入所有的单实例Bean。通过预载入单实例bean ,确保当你需要的时候，你就不用等待，因为它们已经创建好了。
- 一旦单例被实例化就会被放入缓存Bean池，下次获取直接返回，而多例则每一次都创建一个新对象返回，并将控制权移交给用户，由用户管理Bean的生命周期，使用完后需要显示设置为null，帮助回收。BeanFactory只能管理单例Bean，而ApplicationContext也可以管理多例Bean。
- BeanFactory和ApplicationContext都支持BeanPostProcessor、BeanFactoryPostProcessor的使用，但两者之间的区别是：BeanFactory需要手动注册，而ApplicationContext则是自动注册。（Applicationcontext比 beanFactory 加入了一些更好使用的功能。而且 BeanFactory的许多功能需要通过编程实现而 Applicationcontext 可以通过配置实现。比如后处理 bean ， Applicationcontext 直接配置在配置文件即可而 BeanFactory这要在代码中显示的写出来才可以被容器识别）。
- BeanFactory主要是面对与 Spring 框架的基础设施，面对 spring 自己。而Applicationcontext主要面对与 Spring 使用的开发者。基本都会使用 Applicationcontext并非 BeanFactory。
4.Bean的生命周期，以及作用域
1.实例化一个Bean（由BeanFactory读取Bean定义文件，并生成各个实例）－－也就是我们常说的new；
2.按照Spring上下文对实例化的Bean的属性值进行设置－－也就是IOC注入；
3.如果这个Bean已经实现了BeanNameAware接口，会调用它实现的setBeanName(String)方法，此处传递的就是Spring配置文件中Bean的id值
4.如果这个Bean已经实现了BeanFactoryAware接口，会调用它实现的setBeanFactory(setBeanFactory(BeanFactory)传递的是Spring工厂自身（可以用这个方式来获取其它Bean，只需在Spring配置文件中配置一个普通的Bean就可以）；
5.如果这个Bean已经实现了ApplicationContextAware接口，会调用setApplicationContext(ApplicationContext)方法，传入Spring上下文（同样这个方式也可以实现步骤4的内容，但比4更好，因为ApplicationContext是BeanFactory的子接口，有更多的实现方法）；说明如果Bean是由BeanFactory管理，则没有第五步，同样如果由ApplicationContext管理，则没有第四步。
6.如果这个Bean关联了BeanPostProcessor接口，将会调用postProcessBeforeInitialization(Object obj, String s)方法，初始化之前构造注入依赖之后执行；
7.如果Bean类实现了org.springframework.beans.factory.InitializingBean接口，则执行其afterPropertiesSet()方法。
一般是用来在实例构造完成后，实例的应该注入的依赖属性已经完成注入，需要对不需要注入的实例属性进行自定义初始化配置；当然也可指定一个init-method方法完成初始化，两者的作用一样，都是完成用户自定义初始化。对於单例，如果bean实现了InitializingBean接口则afterPropertiesSet方法只会被调用一次；否则每次创建bean时afterPropertiesSet方法都会被重新调用。
8.如果Bean在Spring配置文件中配置了init-method属性会自动调用其配置的初始化方法。或者使用@PostConstruct后构造注解来将任意方法名称的方法标明为一个init-method方法
9.如果这个Bean关联了BeanPostProcessor接口，将会调用postProcessAfterInitialization(Object obj, String s)方法；
注：以上工作完成以后就可以应用这个Bean了，如果这个Bean是一个Singleton的，则将这准备就绪的Bean放入Spring缓存池中，已被下次使用，所以一般情况下我们调用同一个id的Bean会是在内容地址相同的实例，当然在Spring配置文件中也可以配置非Singleton，此时不会将Bean放入缓存池中，而是直接将控制权交给Bean的使用者。
10.当Bean不再需要时，会经过清理阶段，如果Bean实现了DisposableBean这个接口，会调用那个其实现的destroy()方法；
11.最后，如果这个Bean的Spring配置中配置了destroy-method属性，会自动调用其配置的销毁方法。可以使用@PreDestroy前销毁注解，标明一个方法为destroy-method
5.Bean的作用域Scope
通过@Scope注解来标注Bean的作用域
Scope的类型：
主要分为单例（singleton）和多例（除了singleton外的Bean）
1.singleton:单例模式（如果不指定Scope，默认是singleton）
2.Prototype:原型模式
3.request:对于 每次http 请求，bean都会产生一个新的实例，只有在web 应用中才会生效
4.session 对于 每次HttpSession时会产生一个新的实例，只有在web 应用中才会生效
5.global session ,只有在portlet context中有效
比较常用到的是singleton和prototype，java在创建实例，要进行内存申请，销毁实例时，要垃圾回收，这些都会导致系统开销的增加，因此prototype作用域的bean在创建、销毁代价会比较大，而singleton的bean实例，一旦创建，就可以重复使用
单例Bean的线程安全问题
在spring中，singleton属性默认是true，只有设定为false，对单线程的程序说并不会有什么问题，但对于多线程的程序，就必须注意安全(Thread-safe)的议题，防止多个线程同时存取共享资源所引发的数据不同步问题。
如果多线程都会并发的修改Bean的实例字段时，一定要进行同步，如果只是只读共享域则不用关心。注意处理共享字段
Prototype的Bean的使用
多例Bean通过BeanFactory和ApplicationContext 的getBean方法获取，每次返回的都是新创建的Bean；当然单例也可以使用上面方法获得，但是每次返回都是同一个Bean。
bean的注入方式（DI）
1.XML配置方式
2.注解方式
采用注解的方式，比起xml配置方式更加简洁，不然也要注意耦合方面
除了@Component外，Spring提供了3个功能基本和@Component等效的注解，分别对应于用于对DAO，Service，和Controller进行注解。
1：@Repository 用于对DAO实现类进行注解。
2：@Service 用于对业务层注解，但是目前该功能与 @Component 相同。
3：@Constroller用于对控制层注解，但是目前该功能与 @Component 相同。
3.Aotowired自动装配方式
实现自动转配需要两个步骤：
- 组件扫描（component scanning）:Spring会自动发现应用上下文中所创建的bean
- 自动装配（autowiring）：Spring自动满足bean之间的依赖
<!-- 扫描包 -->
<context:component-scan base-package="com.test" />
<!-- 注解映射支持 -->
<mvc:annotation-drivern/>
@Autowired，该注解的作用是：可以对成员变量、方法和构造函数进行注解，来完成自动装配的工作，通俗来说就是会根据类型从容器中自动查到到一个Bean给bookDAO字段。@Autowired是根据类型进行自动装配的，如果需要按名称进行装配，则需要配合@Qualifier。另外可以使用其它注解，
@ Resource ：等同于@Qualifier
@Inject：等同于@ Autowired。
@Service用于注解业务层组件（我们通常定义的service层就用这个）
@Controller用于注解控制层组件（如struts中的action）
@Repository用于注解数据访问组件，即DAO组件
@Component泛指组件，当组件不好归类的时候，我们可以使用这个注解进行注解。
装配注解的使用
装配注解主要有：@Autowired、@Qualifier、@Resource，它们的特点是：
@Resource
默认是按照名称来装配注入的，只有当找不到与名称匹配的bean才会按照类型来装配注入；
@Autowired
默认是按照类型装配注入的，如果想按照名称来转配注入，则需要结合@Qualifier一起使用；
@Resource
注解是又J2EE提供，而@Autowired是由spring提供，故减少系统对spring的依赖建议使用@Resource的方式；如果Maven项目是1.5的JRE则需换成更高版本的。
@Resource和@Autowired都可以书写注解在字段或者该字段的setter方法之上
@Autowired
可以对成员变量、方法以及构造函数进行注释，而 @Qualifier 的注解对象是成员变量、方法入参、构造函数入参。
@Qualifier("XXX")
中的 XX是 Bean 的名称，所以 @Autowired 和 @Qualifier 结合使用时，自动注入的策略就从 byType 转变成 byName 了。
@Autowired 注释进行自动注入时
Spring 容器中匹配的候选 Bean 数目必须有且仅有一个，通过属性required可以设置非必要。
@Resource装配顺序
如果同时指定了name和type，则从Spring上下文中找到唯一匹配的bean进行装配，找不到则抛出异常
如果指定了name，则从上下文中查找名称（id）匹配的bean进行装配，找不到则抛出异常
如果指定了type，则从上下文中找到类型匹配的唯一bean进行装配，找不到或者找到多个，都会抛出异常
如果既没有指定name，又没有指定type，则自动按照byName方式进行装配；如果没有匹配，则回退为一个原始类型进行匹配，如果匹配则自动装配；
参照：
https://howtodoinjava.com/spring-core/spring-bean-life-cycle/