1,實例化bean
就Spring IoC容器而言，bean定義基本上描述了創建一個或多個實際bean對象的內容。當需要的時候，容器會從bean定義列表中取得一個指定的bean定義，并根據bean定義里面的配置元數據使用反射機制來創建一個實際的對象。因此這一節將講解如何告知Spring IoC容器我們將要實例化的對象的類型以及如何實例化對象。
當采用XML描述配置元數據時，將通過<bean/>元素的class屬性來指定實例化對象的類型。class 屬性 (對應BeanDefinition實例的Class屬性)通常是必須的(不過也有兩種例外的情形，“使用實例工廠方法實例化”和“bean定義的繼承”)。class屬性主要有兩種用途：在大多數情況下，容器將直接通過反射調用指定類的構造器來創建bean(這有點等類似于在Java代碼中使用new操作符)；在極少數情況下，容器將調用類的靜態工廠方法來創建bean實例，class屬性將用來指定實際具有靜態工廠方法的類(至于調用靜態工廠方法創建的對象類型是當前class還是其他的class則無關緊要)。
2, 延遲初始化bean
ApplicationContext實現的默認行為就是在啟動時將所有singleton bean提前進行實例化。提前實例化意味著作為初始化過程的一部分，ApplicationContext實例會創建并配置所有的singleton bean。通常情況下這是件好事，因為這樣在配置中的任何錯誤就會即刻被發現（否則的話可能要花幾個小時甚至幾天）。
有時候這種默認處理可能并不是你想要的。如果你不想讓一個singleton bean在ApplicationContext實現在初始化時被提前實例化，那么可以將bean設置為延遲實例化。一個延遲初始化bean將告訴IoC 容器是在啟動時還是在第一次被用到時實例化。
在XML配置文件中，延遲初始化將通過<bean/>元素中的lazy-init屬性來進行控制。例如：
<bean id="lazy" class="com.foo.ExpensiveToCreateBean" lazy-init="true">
<!-- various properties here... -->
</bean>
<bean name="not.lazy" class="com.foo.AnotherBean">
<!-- various properties here... -->
</bean>
當ApplicationContext實現加載上述配置時，設置為lazy的bean將不會在ApplicationContext啟動時提前被實例化，而not.lazy卻會被提前實例化。
需要說明的是，如果一個bean被設置為延遲初始化，而另一個非延遲初始化的singleton bean依賴于它，那么當ApplicationContext提前實例化singleton bean時，它必須也確保所有上述singleton 依賴bean也被預先初始化，當然也包括設置為延遲實例化的bean。因此，如果Ioc容器在啟動的時候創建了那些設置為延遲實例化的bean的實例，你也不要覺得奇怪，因為那些延遲初始化的bean可能在配置的某個地方被注入到了一個非延遲初始化singleton bean里面。
在容器層次中通過在<beans/>元素上使用'default-lazy-init'屬性來控制延遲初始化也是可能的。如下面的配置：
<beans default-lazy-init="true">
<!-- no beans will be eagerly pre-instantiated... -->
</beans>
3,自動裝配（autowire）協作者
Spring IoC容器可以自動裝配（autowire）相互協作bean之間的關聯關系。因此，如果可能的話，可以自動讓Spring通過檢查BeanFactory中的內容，來替我們指定bean的協作者（其他被依賴的bean）。由于autowire可以針對單個bean進行設置，因此可以讓有些bean使用autowire，有些bean不采用。autowire的方便之處在減少或者消除屬性或構造器參數的設置，這樣可以給我們的配置文件減減肥！[2] 在xml配置文件中，autowire一共有五種類型，可以在<bean/>元素中使用autowire屬性指定:
Table 3.2. Autowiring modes
模式 說明
no 不使用自動裝配。必須通過ref元素指定依賴，這是默認設置。由于顯式指定協作者可以使配置更靈活、更清晰，因此對于較大的部署配置，推薦采用該設置。而且在某種程度上，它也是系統架構的一種文檔形式。
byName 根據屬性名自動裝配。此選項將檢查容器并根據名字查找與屬性完全一致的bean，并將其與屬性自動裝配。例如，在bean定義中將autowire設置為by name，而該bean包含master屬性（同時提供setMaster(..)方法），Spring就會查找名為master的bean定義，并用它來裝配給master屬性。
byType 如果容器中存在一個與指定屬性類型相同的bean，那么將與該屬性自動裝配。如果存在多個該類型的bean，那么將會拋出異常，并指出不能使用byType方式進行自動裝配。若沒有找到相匹配的bean，則什么事都不發生，屬性也不會被設置。如果你不希望這樣，那么可以通過設置dependency-check="objects"讓Spring拋出異常。
constructor 與byType的方式類似，不同之處在于它應用于構造器參數。如果在容器中沒有找到與構造器參數類型一致的bean，那么將會拋出異常。
autodetect 通過bean類的自省機制（introspection）來決定是使用constructor還是byType方式進行自動裝配。如果發現默認的構造器，那么將使用byType方式。
如果直接使用property和constructor-arg注入依賴的話，那么將總是覆蓋自動裝配。而且目前也不支持簡單類型的自動裝配，這里所說的簡單類型包括基本類型、String、Class以及簡單類型的數組（這一點已經被設計，將考慮作為一個功能提供）。自動裝配還可以與依賴檢查結合使用，這樣依賴檢查將在自動裝配完成之后被執行。
理解自動裝配的優缺點是很重要的。其中優點包括：
自動裝配能顯著減少配置的數量。不過，采用bean模板（見這里）也可以達到同樣的目的。
自動裝配可以使配置與java代碼同步更新。例如，如果你需要給一個java類增加一個依賴，那么該依賴將被自動實現而不需要修改配置。因此強烈推薦在開發過程中采用自動裝配，而在系統趨于穩定的時候改為顯式裝配的方式。
自動裝配的一些缺點：
盡管自動裝配比顯式裝配更神奇，但是，正如上面所提到的，Spring會盡量避免在裝配不明確的時候進行猜測，因為裝配不明確可能出現難以預料的結果，而且Spring所管理的對象之間的關聯關系也不再能清晰的進行文檔化。
對于那些根據Spring配置文件生成文檔的工具來說，自動裝配將會使這些工具沒法生成依賴信息。
如果采用by type方式自動裝配，那么容器中類型與自動裝配bean的屬性或者構造函數參數類型一致的bean只能有一個，如果配置可能存在多個這樣的bean，那么就要考慮采用顯式裝配了。
盡管使用autowire沒有對錯之分，但是能在一個項目中保持一定程度的一致性是最好的做法。例如，通常情況下如果沒有使用自動裝配，那么僅自動裝配一個或兩個bean定義可能會引起開發者的混淆。