面試快被問爛的 Spring IoC，還不趕忙梳理一下

IoC 是 Inverse of Control 的縮寫，翻譯過來叫作控制反轉，它不是什麼技術，而是一種設計思想。

什麼是 IoC

在傳統的 Java 程序中，咱們都是在對象內部經過 new 主動進行對象建立的；而 IoC 是專門有一個容器來建立這些對象，當程序須要這些對象的時候，不須要顯式地使用 new 建立，而是由 IoC 容器完成對象的注入。

下面舉個例子加深理解：

古時候皇帝想寵幸某個妃子，就會直接說，今天選熹妃，後面的事情就交給太監辦了；皇帝晚上回宮時，熹妃天然會出如今龍牀上。

整個後宮就是 Spring 容器，妃子就是 Spring 控制下的 JavaBean ，從選妃到入宮再到廢除，這是 JavaBean 的生命週期，太監宮女就是 BeanFactory ，而侍寢的整個過程就是控制反轉，皇帝不須要知道妃子父母是誰（構造函數是什麼樣的），何時入的宮（何時初始化），只須要說須要熹妃仍是華妃就能夠了。

*這樣說是否是就容易理解了，固然面試的時候千萬別這樣講。

IoC 的優缺點

• 由於採用了依賴注入，在初始化的過程當中，避免寫大量的 new ，並且這樣也就不須要了解其中的細節，好比不須要搞清楚每一個 Bean 構造函數的參數；
• IoC 實現組件之間的解耦，提升程序的靈活性和可維護性。一樣的，IoC 讓建立對象的步驟變複雜了，由於用反射來建立對象，因此在效率上會有些損耗；
• 不過相比「解耦」的做用，這點兒損耗也顯得微不足道了。

Spring IoC 加載過程

再簡單地總結一下 Spring IoC 加載的所有過程，大體可分爲定位、解析、註冊、實例化四個步驟：

• 定位：就是資源文件定位，資源文件能夠是文件、URL、二進制數組，和Bean配置有關的一般是 XML / @Configuration / 註解（Java文件）；通常是在 ApplicationContext 的實現類裏完成的，能夠將外部的資源，讀取爲 Resource 類。
• 解析：解析就只對資源文件的解析；解析主要是在 BeanDefinitionReader 中完成的；好比最多見的 XML 配置文件，那麼將解析工做委託給 XmlBeanDefinitionReader 來完成；解析最終解析的結果都封裝爲 BeanDefinitionHolder ；
• 註冊：所謂的註冊，其實就是將 BeanDefinition 的 Name 和實例，保存到一個 Map 中；bean 的註冊是在 BeanFactory 裏完成的；BeanFactory 接口最多見的一個實現類是 DefaultListableBeanFactory ，其中的 Map 就是 BeanDefinitionMap ，是一個 ConcurrentHashMap 。
• 實例化：註冊完成後，在 BeanFactory 的 getBean() 方法之中，完成初始化；這時候應用程序就能夠直接使用 Bean 了。

固然，關於 Spring IoC 還有不少細節須要瞭解，好比 Bean 的做用域、生命週期，後面我會從源碼的角度，分析講解。

會點代碼的大叔 | 文【原創】

---

image.png