我們日常的工作中常常出現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更容易理解。
參考文獻：