轉載：https://blog.csdn.net/hht006158/article/details/80181207。
Spring是一個開源框架，Spring是於2003 年興起的一個輕量級的Java 開發框架，由Rod Johnson 在其著作Expert One-On-One J2EE Development and Design中闡述的部分理念和原型衍生而來。它是為了解決企業應用開發的復雜性而創建的。框架的主要優勢之一就是其分層架構，分層架構允許使用者選擇使用哪一個組件，同時為 J2EE 應用程序開發提供集成的框架。Spring使用基本的JavaBean來完成以前只可能由EJB完成的事情。然而，Spring的用途不僅限於服務器端的開發。從簡單性、可測試性和松耦合的角度而言，任何Java應用都可以從Spring中受益。Spring的核心是控制反轉（IoC）和面向切面（AOP）。簡單來說，Spring是一個分層的JavaSE/EEfull-stack(一站式) 輕量級開源框架。
特點：
簡單理解
一.概念：
1. spring是開源的輕量級框架
2 spring核心主要兩部分：
（1）aop：面向切面編程，擴展功能不修改源代碼實現,詳解【http://www.cnblogs.com/landeanfen/p/4782370.html】
（2）ioc：控制反轉
比如有一個類，在類里面有方法（不是靜態的方法），調用類里面的方法，創建類的對象，使用對象調用方法，創建類對象的過程，需要new出來對象， 把對象的創建不是通過new方式實現，而是交給spring配置創建類對象。
我用通俗的話給你解釋把。首先你不用框架不是每次創建對象都要用關鍵字“new”呢？對吧。有了spring配置就不用new了，直接拿。舉個例子：假如你吃飯，每次你要吃飯時都要自己准備碗和筷子，每次都要自己准備，用了框架后，再 吃飯你只要吃就行了，就不用准備碗和筷子了因為spring已經給你准備好了。這樣是不是很方便。 spring主要就是不用你自己創建對象，都配置在配置文件中。如果你寫好一個項目，你再a類中創建了b類的方法，c類也創建了b類的方法，如果那天要改b類的類名，你就要在a和c中都改，如果有100個類都用了b類呢？那你不是要改死哦！！ 如果用了spring，你只要修改配置文件一個位置就好了，是不是很方便維護呢。所以，小項目用不着spring框架。手打好累。。。
ioc：控制反轉
ioc的思想最核心的地方在於，資源不由使用資源的雙方管理，而由不使用資源的第三方管理，這可以帶來很多好處。第一，資源集中管理，實現資源的可配置和易管理。第二，降低了使用資源雙方的依賴程度，也就是我們說的耦合度。
也就是說，甲方要達成某種目的不需要直接依賴乙方，它只需要達到的目的告訴第三方機構就可以了，比如甲方需要一雙襪子，而乙方它賣一雙襪子，它要把襪子賣出去，並不需要自己去直接找到一個賣家來完成襪子的賣出。它也只需要找第三方，告訴別人我要賣一雙襪子。這下好了，甲乙雙方進行交易活動，都不需要自己直接去找賣家，相當於程序內部開放接口，賣家由第三方作為參數傳入。甲乙互相不依賴，而且只有在進行交易活動的時候，甲才和乙產生聯系。反之亦然。這樣做什么好處么呢，甲乙可以在對方不真實存在的情況下獨立存在，而且保證不交易時候無聯系，想交易的時候可以很容易的產生聯系。甲乙交易活動不需要雙方見面，避免了雙方的互不信任造成交易失敗的問題。因為交易由第三方來負責聯系，而且甲乙都認為第三方可靠。那么交易就能很可靠很靈活的產生和進行了。
這就是ioc的核心思想。生活中這種例子比比皆是，支付寶在整個淘寶體系里就是龐大的ioc容器，交易雙方之外的第三方，提供可靠性可依賴可靈活變更交易方的資源管理中心。另外人事代理也是，雇佣機構和個人之外的第三方。
控制反轉( Inversion of Control ), 我覺得有必要先了解軟件設計的一個重要思想：依賴倒置原則（Dependency Inversion Principle ）。
什么是依賴倒置原則？假設我們設計一輛汽車：先設計輪子，然后根據輪子大小設計底盤，接着根據底盤設計車身，最后根據車身設計好整個汽車。這里就出現了一個“依賴”關系：汽車依賴車身，車身依賴底盤，底盤依賴輪子。
這樣的設計看起來沒問題，但是可維護性卻很低。假設設計完工之后，上司卻突然說根據市場需求的變動，要我們把車子的輪子設計都改大一碼。這下我們就蛋疼了：因為我們是根據輪子的尺寸設計的底盤，輪子的尺寸一改，底盤的設計就得修改；同樣因為我們是根據底盤設計的車身，那么車身也得改，同理汽車設計也得改——整個設計幾乎都得改！
我們現在換一種思路。我們先設計汽車的大概樣子，然后根據汽車的樣子來設計車身，根據車身來設計底盤，最后根據底盤來設計輪子。這時候，依賴關系就倒置過來了：輪子依賴底盤， 底盤依賴車身， 車身依賴汽車。
這時候，上司再說要改動輪子的設計，我們就只需要改動輪子的設計，而不需要動底盤，車身，汽車的設計了。
這就是依賴倒置原則——把原本的高層建築依賴底層建築“倒置”過來，變成底層建築依賴高層建築。高層建築決定需要什么，底層去實現這樣的需求，但是高層並不用管底層是怎么實現的。這樣就不會出現前面的“牽一發動全身”的情況。
控制反轉（Inversion of Control） 就是依賴倒置原則的一種代碼設計的思路。具體采用的方法就是所謂的依賴注入（Dependency Injection）。其實這些概念初次接觸都會感到雲里霧里的。說穿了，這幾種概念的關系大概如下：
為了理解這幾個概念，我們還是用上面汽車的例子。只不過這次換成代碼。我們先定義四個Class，車，車身，底盤，輪胎。然后初始化這輛車，最后跑這輛車。代碼結構如下：
這樣，就相當於上面第一個例子，上層建築依賴下層建築——每一個類的構造函數都直接調用了底層代碼的構造函數。假設我們需要改動一下輪胎（Tire）類，把它的尺寸變成動態的，而不是一直都是30。我們需要這樣改：
由於我們修改了輪胎的定義，為了讓整個程序正常運行，我們需要做以下改動：
由此我們可以看到，僅僅是為了修改輪胎的構造函數，這種設計卻需要修改整個上層所有類的構造函數！在軟件工程中，這樣的設計幾乎是不可維護的——在實際工程項目中，有的類可能會是幾千個類的底層，如果每次修改這個類，我們都要修改所有以它作為依賴的類，那軟件的維護成本就太高了。
所以我們需要進行控制反轉（IoC），及上層控制下層，而不是下層控制着上層。我們用依賴注入（Dependency Injection）這種方式來實現控制反轉。所謂依賴注入，就是把底層類作為參數傳入上層類，實現上層類對下層類的“控制”。這里我們用構造方法傳遞的依賴注入方式重新寫車類的定義：
這里我們再把輪胎尺寸變成動態的，同樣為了讓整個系統順利運行，我們需要做如下修改：
看到沒？這里我只需要修改輪胎類就行了，不用修改其他任何上層類。這顯然是更容易維護的代碼。不僅如此，在實際的工程中，這種設計模式還有利於不同組的協同合作和單元測試：比如開發這四個類的分別是四個不同的組，那么只要定義好了接口，四個不同的組可以同時進行開發而不相互受限制；而對於單元測試，如果我們要寫Car類的單元測試，就只需要Mock一下Framework類傳入Car就行了，而不用把Framework, Bottom, Tire全部new一遍再來構造Car。
這里我們是采用的構造函數傳入的方式進行的依賴注入。其實還有另外兩種方法：Setter傳遞和接口傳遞。這里就不多講了，核心思路都是一樣的，都是為了實現控制反轉。
看到這里你應該能理解什么控制反轉和依賴注入了。那什么是控制反轉容器(IoC Container)呢？其實上面的例子中，對車類進行初始化的那段代碼發生的地方，就是控制反轉容器。
顯然你也應該觀察到了，因為采用了依賴注入，在初始化的過程中就不可避免的會寫大量的new。這里IoC容器就解決了這個問題。這個容器可以自動對你的代碼進行初始化，你只需要維護一個Configuration（可以是xml可以是一段代碼），而不用每次初始化一輛車都要親手去寫那一大段初始化的代碼。這是引入IoC Container的第一個好處。
IoC Container的第二個好處是：我們在創建實例的時候不需要了解其中的細節。在上面的例子中，我們自己手動創建一個車instance時候，是從底層往上層new的：
這個過程中，我們需要了解整個Car/Framework/Bottom/Tire類構造函數是怎么定義的，才能一步一步new/注入。
而IoC Container在進行這個工作的時候是反過來的，它先從最上層開始往下找依賴關系，到達最底層之后再往上一步一步new（有點像深度優先遍歷）：
這里IoC Container可以直接隱藏具體的創建實例的細節，在我們來看它就像一個工廠：
我們就像是工廠的客戶。我們只需要向工廠請求一個Car實例，然后它就給我們按照Config創建了一個Car實例。我們完全不用管這個Car實例是怎么一步一步被創建出來。
實際項目中，有的Service Class可能是十年前寫的，有幾百個類作為它的底層。假設我們新寫的一個API需要實例化這個Service，我們總不可能回頭去搞清楚這幾百個類的構造函數吧？IoC Container的這個特性就很完美的解決了這類問題——因為這個架構要求你在寫class的時候需要寫相應的Config文件，所以你要初始化很久以前的Service類的時候，前人都已經寫好了Config文件，你直接在需要用的地方注入這個Service就可以了。這大大增加了項目的可維護性且降低了開發難度。