bean 的生命周期
对象创建
-
实例化Bean对象，默认选择无参构造方法，如果只有一个有参构造那么调用有参构造，如果只有多个有参构造那么报错，除非其中一个有参构造添加了@AutoWired注解；
设置Bean的属性；
依赖注入以及判断是否实现了Aware相关接口（BeanNameAware, BeanFactoryAware, ApplicationContextAware）
如果这个 Bean 关联了 BeanPostProcessor 接口，将会调用BeanPostProcessor.postProcessorBeforeInitialization()
判断是否实现了InitalizingBean接口，实现了就执行 InitalizingBean.afterPropertiesSet() 方法
如果Bean在配置文件中的定义包含init-method属性（或者添加了@PostConstruct注解），执行指定的方法；
执行方法BeanPostProcessor.postProcessorAfterInitialization()：例如判断有没有实现AOP
创建对象完毕；
对象销毁
-
当要销毁Bean的时候，如果Bean实现了DisposableBean接口，执行destroy()方法。
当要销毁Bean的时候，如果Bean在配置文件中的定义包含destroy-method属性（或者添加了@PreDestroy注解），执行指定的方法
销毁对象完毕
Bean 的作用域
spring 支持 5 种作用域，如下：
request：每一次HTTP请求都会产生一个新的bean，该bean仅在当前HTTP request内有效。
singleton：：单例模式，Spring IoC 容器中只会存在一个共享的 Bean 实例，无论有多少个Bean 引用它，始终指向同一对象。该模式在多线程下是不安全的。Singleton 作用域是Spring 中的默认作用域 prototype：每次通过 Spring 容器获取 prototype 定义的 bean 时，容器都将创建一个新的 Bean 实例，每个 Bean 实例都有自己的属性和状态，而 singleton 全局只有一个对象。根据经验，对有状态的bean使用prototype作用域，而对无状态的bean使用singleton作用域。 用于与数据库交互的存储数据的bean等，均是有状态的bean。 而仅仅用于操作其他资源的bean，如service controller，就是无状态的bean。 当然，由于spring使用了ThreadLocal进行多线程处理，绝大多数bean都可以声明为singleton作用域。这是后话。 session：在一次 Http Session 中，容器会返回该 Bean 的同一实例。而对不同的 Session 请求则会创建新的实例，该 bean 实例仅在当前 Session 内有效。同 Http 请求相同，每一次session 请求创建新的实例，而不同的实例之间不共享属性，且实例仅在自己的 session 请求内有效，请求结束，则实例将被销毁。如用户购物车 global-session：全局session作用域，仅仅在基于Portlet的Web应用中才有意义，Spring5中已经没有了。Portlet是能够生成语义代码（例如HTML）片段的小型Java Web插件。它们基于Portlet容器，可以像Servlet一样处理HTTP请求。但是与Servlet不同，每个Portlet都有不同的会话。bean的循环依赖
什么是循环依赖
一个AService里面引用了BService的一个对象，BService里面又引用了AService的一个对象。
那么在构造AService的bean的时候，会填充属性以及注入依赖，那么就需要注入BService的bean，spring发现BService的bean还没有创建，又会去构造BService的bean。同理BService的bean又需要AService的bean，这时候因为AService的bean还没有构建好，所以他也会去创建AService的bean。一直循环
怎么解决：使用二级缓存
singletonObjects：第一级缓存，里面放置的是实例化好的单例对象；这个是一直存在的 earlySingletonObjects：第二级缓存，里面存放的是提前曝光的单例对象；就是下面图中的那个缓存
有什么问题
如果上述的bean不存在AOP，那么是没有什么问题的，但是如果存在AOP的话，那么构造出来的bean对象就不是原始对象了，而是AOP生成的代理对象。如果还是使用二级缓存的话，那么B从缓存取的是A的原始对象而不是构造好的A的bean对象
怎么解决
添加一层缓存，singletonFactories：第三级缓存，里面存放的是要被实例化的对象的对象工厂。
主要代码如下：
protected Object getSingleton(String beanName, boolean allowEarlyReference) {
Object singletonObject = this.singletonObjects.get(beanName);
if (singletonObject == null && isSingletonCurrentlyInCreation(beanName)) {
synchronized (this.singletonObjects) {
singletonObject = this.earlySingletonObjects.get(beanName);
if (singletonObject == null && allowEarlyReference) {
ObjectFactory<?> singletonFactory = this.singletonFactories.get(beanName);
if (singletonFactory != null) {
singletonObject = singletonFactory.getObject();
this.earlySingletonObjects.put(beanName, singletonObject);
this.singletonFactories.remove(beanName);
}
}
}
}
return (singletonObject != NULL_OBJECT ? singletonObject : null);
}
分析getSingleton()的整个过程，Spring首先从一级缓存singletonObjects中获取。如果获取不到，并且对象正在创建中，就再从二级缓存earlySingletonObjects中获取。如果还是获取不到且允许singletonFactories通过getObject()获取，就从三级缓存singletonFactory.getObject()(三级缓存)获取，如果获取到了则从singletonFactories中移除，并放入earlySingletonObjects中。其实也就是从三级缓存移动到了二级缓存。
总结一下流程：
A在第一步实例化对象之后将自己提前曝光到singletonFactories中 在填充属性时发现自己依赖对象B，此时就尝试去get(B)，发现B还没有被create，所以走create流程 B在填充属性的时候发现自己依赖了对象A，于是尝试get(A)，尝试一级缓存singletonObjects(肯定没有，因为A的bean还没有构造完)，尝试二级缓存earlySingletonObjects（也没有），尝试三级缓存singletonFactories，由于A通过ObjectFactory将自己提前曝光了，所以B能够通过ObjectFactory.getObject拿到A对象 通过提前引用，直接创建出A的动态代理对象也就是实例化好的A的bean放到第二个缓存中，这样B的bean就直接实例化完成进入一级缓存。 此时回调到A中，A填充属性这一步完成了继续往下执行，因为bean是单例的，所以A不会又去调用动态代理再创建一个bean，而是直接从第二个缓存里拿出实例化好的那个bean出来直接用放进一级缓存中。