我们日常的工作中常常出现bean之间的相互依赖，如果使用xml配置，常常比较清晰，如下：
而JavaConfig中的配置往往如下：
最初看到这段代码就在想Spring是如何来管理这种依赖，由于默认情况下bean会被设置成单例的，因此这里foo调用的bar方法返回的bean实例应该与容器中的bar是同一实例，随后通过测试代码也验证了这一想法，并且无论调用多少次bar方法返回的都是同一个对象，因此bar肯定是被缓存起来了，而且由于调用bar时并没有产生新的对象，因此调用的AppConfig应该是被代理过的，代理过的代码大致为：
于是通过查看资料，以及查看源码与debug的方式来验证，大致的过程为，在容器启动的过程中，先将AppConfig注册到容器中，然后执行refresh时会查找所有的BeanFactoryPostProcessor并执行，其中有一个ConfigurationClassPostProcessor专门来处理@Configuration的配置类，主要有两个作用，首先是将@Bean注解的方法注册到容器中，其次就是对AppConfig进行代理，在执行@Bean方法时会检查bean是否已经创建，如果创建好了直接返回就好了，如果没有则调用原生方法创建。
JavaConfig为什么需要支持这种特性呢，如果不支持的话我们应该如何实现呢。可能的方法有将bar作为Foo中的一个可以注入的属性，这种方式有一个缺点是Foo需要我们能够控制，而一些二方库包中的代码我们往往无法修改。另外一种方式是将bar作为foo方法的入参，在foo方法中设置进去。而像lookup method injection 这种存在依赖关系的bean之间生命周期不一致的情况下，则需要依赖ApplicationContext来每次生成一个新的bean，并进行属性注入，这样就导致业务代码混入了容器代码了。因此JavaConfig的依赖管理方式带来了两种好处，第一是方便配置，直接在需要依赖的地方调用方法即可；第二是解开了与容器的耦合，而且比xml配置的lookup method更容易理解。
参考文献：