除了管理Bean与Bean之间的关系，IoC还提供了对Bean自身进行控制的各项功能，本文将介绍Bean的生命周期功能以及状态定义功能。
前置依赖
Bean与Bean之间存在依赖关系，可以是强依赖（通过XML和注解直接声明依赖）、也可以是弱依赖（ApplicationContextAware等方式获取）。当一个Bean需要另外一个Bean完成初始化后自身才能工作时，例如一个Bean依赖DataSoruce，但是DataSource的初始化需要较长时间。这个时候用depends-on声明前置依赖即可：
<!-- 依赖多个Bean使用,号分割 -->
<bean id="beanOne" class="ExampleBean" depends-on="manager,accountDao">
<property name="manager" ref="manager" />
</bean>
<bean id="manager" class="ManagerBean" />
<bean id="accountDao" class="x.y.jdbc.JdbcAccountDao" />
延迟加载
通常情况下，所有的 singleton 类型的Bean都会在容器创建后进行初始化，简单的说就是启动Jvm就开始创建（实际上是创建ApplicationContext的某个实现类实例之后）。
IoC支持所有的 singleton Bean在使用时再加载，这样做的好处是可以大大节省初始化的时间。但是如果你的应用对启动时间的长短并不敏感，建议让所有的 singleton 都启动时加载。这样可以在启动时就发现一些问题，而不是在运行很久直到使用时才由用户去触发这个问题。或者可以根据场景来使用决定是否延迟，例如开发时使用延迟加载，而在集成测试或上生产时关闭。
可以设置全局延迟加载，也可以设置某个Bean延迟加载：
<beans default-lazy-init="true">
<!-- 所有的Bean知道使用的时候才会进行加载... -->
</beans>
<!-- 只有lazy类延迟加载 -->
<bean id="lazy" class="com.foo.ExpensiveToCreateBean" lazy-init="true"/>
<bean name="not.lazy" class="com.foo.AnotherBean"/>
需要注意的是，在设置某个单独的Bean延迟加载时，如果有某个没有延迟加载的Bean要依赖他，那实际上也会在初始化的时候就加载。
还要强调一下，这里的“加载”仅仅是为了表示一个类被Ioc创造并放置容器中，和classLoad方法将class文件中的字节码加载到方法区的加载是两个概念。
延迟加载在设计模式上是单例模式一种延伸，通常也被称为懒汉模式。单例通常有双重锁+volatile、静态类和枚举三种方式实现。在Effective Java一书中对三种模式都有深入的解析。而对于Spring容器而言，枚举的方式肯定不好用了，静态类由于属于自身代码级别应该也不会用，所以双重锁的实现方式较为可信。不过我没去看过源码，仅属于猜测。
生命周期方法
一个Bean的创建、使用再到最后销毁称为"Bean的生命周期"。Spring框架为Bean的生命周期各个阶段提供了多种回掉方法来处理各种状态或者数据。
初始化方法
当一个Bean完成初始化并注入各项参数之后，初始化回掉方法会被调用，简单的说就是完成创建之后会被调用。实现初始化回调方法有2个路径：1.继承org.springframework.beans.factory.InitializingBean接口，然后实现 afterPropertiesSet方法。2.在Bean的XML配置上使用init-method属性来制定要调用的初始化：
继承实现：
<bean id="a" class="x.y.A" />
package x.y;
public class A implements InitializingBean {
public void afterPropertiesSet(){
// init
}
}
配置实现：
<bean id="a" class="x.y.A" init-method="init" />
package x.y;
public class A {
public void init(){}
}
2种方法都等效，实际使用是我们应该使用哪一种方法呢？
InitializingBean是Spring早期实现的一个生命周期回调方法。但是在JCP推出JSR-250和JSR-330规范之后，Spring的大神们开始意识到基于元编程思想和配置手段来实现非侵入式框架（Not Coupled）才是正道。所以现在都是推荐使用配置文件和JSR-250的@PostConstruct（关于各种Annotation的使用请关注后续的文章）。现在依然保留InitializingBean应该是考虑到兼容问题。
销毁方法
与创建方法相对应的是销毁方法。当一个类将要被销毁之前，对应的销毁回调方法会被调用。销毁方法也有一个继承实现和配置+注解实现：
继承实现：
<bean id="a" class="x.y.A" />
package x.y;
public class A implements DisposableBean {
public void destroy(){
// 销毁资源
}
}
配置实现：
<bean id="a" class="x.y.A" destroy-method="cleanUp" />
package x.y;
public class A {
public void cleanUp(){
// 销毁资源
}
}
依然建议销毁手段也使用配置或@PreDestroy来设定销毁方法。
全局配置初始化与销毁方法
IoC容器还提供了全局配置初始化与销毁方法的配置：
package x.y;
public class A {
public void init(){
// 初始化资源
}
public void destroy(http://www.my516.com){
// 销毁资源
}
}
<beans default-init-method="init" default-destroy-method="destroy">
<bean id="a" class="x.y.A"/>
<!-- bean configuration -->
</beans>
通过在<beans>标签上使用default-init-method和default-destroy-method 属性参数，可以为容器中所有的Bean统一指定初始化和销毁的生命周期方法。
如果在<beans>上设定2个默认的生命周期方法，同时在<bean>上也指定了init-method或destroy-method，回调方法会以<bean>上的配置为准。这样就保证全局配置与单独配置可以共存。
使用初始化或销毁2个生命周期方法注意的要点：
初始化和销毁都提供了3种手段：XML配置、注解、以及实现接口。系统的各个部分会交由不同的团队开发，不遵循统一的规范，建议使用满足JSR规范的注解——@PostConstruct、@PreDestroy。如果是统一的团队，准训一致的规范，建议使用<beans>的属性统一名称使用全局配置。
如果Bean设计到代理模式时（例如使用了AOP），那么生命周期方法被调用时，有可能代理类还没有被创建出来。因为生命周期方法是实体类完成对应工作之后就会被调用，而与代理类无关。
欢迎工作一到五年的Java工程师朋友们加入Java技术交流群：659270626
群内提供免费的Java架构学习资料（里面有高可用、高并发、高性能及分布式、Jvm性能调优、Spring源码，MyBatis，Netty,Redis,Kafka,Mysql,Zookeeper,Tomcat,Docker,Dubbo,Nginx等多个知识点的架构资料）合理利用自己每一分每一秒的时间来学习提升自己，不要再用"没有时间“来掩饰自己思想上的懒惰！趁年轻，使劲拼，给未来的自己一个交代！
---------------------